Best solutions for cross project collaboration

Benjamin Stapleton

Im working with a medium size organization that has all of their internal teams using company-managed service projects (HR, Finance, Payroll, IT, etc each with their own project).
The services they provide are available to staff through a portal, all good. 

However, when an issue requires activities from several different teams they dont have a good way of collaborating. Several of the projects contain sensitive information, so providing Service Desk Customer access to other teams is not an option.

 

An example use case is: A user who is leaving the company raises a query to the Payroll project asking what their final paycheck amount will be. To answer this, Payroll need the HR team to confirm end date, outstanding holiday etc. Both the Payroll Project and HR Project contain sensitive data, so neither team can be able to the issues in their queue. Both teams would like an issue for their work, so it appears in reporting/stats. 

What the best solution here?

Im currently thinking of providing the Create Issues and Link Issues permissions to Jira Software Users, which I believe should enable teams to create linked tasks in different projects to collaborate, and should be scalable as more teams begin to discover the need to collaborate between projects. 
Is there any downside to this approach? 

Matthias Gaiser _K15t_

Hey @Benjamin Stapleton,

thank you for the detailed description of your use case - that helps in providing a good answer.

You asked:

Is there any downside to this approach? 

If I understood it correct, people from one team shouldn't be able to view issues in another team's project due to data security reasons, right? Therefore giving them create and link permissions might work, but they wouldn't be able to see it afterwards anymore.

I see multiple possible solution approaches for this:

• Use Issue Security Schemes
  You can work with creating issues and link them together. If it's ok from a data security point of view, I suggest to make only these created issues accesible to the other team. You could do so by using issue security schemes and restricting all issues besides the ones which should be shared.
• Use Automation
  You could define an automation which creates issues in the other project and links them together. You could trigger this based on a comment with a certain keyword, and this comment could become the other issues's summary or description.
  When the issue is done or they need additional input, you can use another automation rule to feed the response back to the original issue.
• Use an issue sync app
  If that's all too cumbersome for you to setup and maintain, you could also use an issue sync app. With such an app, you can configure certain rules when an issue should be shared with another project and define which fields/comments/attachments you'd like to share.
  It could look like this: If a user needs help from the HR team in the Payroll project, they flag the issue with a label "HR" - which syncs over the ticket to the HR project. They can then use the comments to communicate with the HR team.
  In the HR project, it would be created as any request in their JSM project, so they can use private comments to communicate internally and public comments to communicate back to the Payroll team. Once they're done, the Payroll team will see the update in their jira and are able to communicate back to the customer.

There are probably also some other ways - that's all which come to my mind right now.

Cheers,
Matthias

PS: I'm part of the team behind Backbone Issue Sync which can offer you the third solution approach.