Collaboration over restricted projects

[MarcSch]

Hi community,

we are internally discussing options to configure our Jira instance to be able to allow sharing tasks over multiple projects and I'm interested in your opinions.

Background

• Multiple JSM projects, generally one for each department. Access for other departments is not allowd.
• Need to share tasks between projects.
• Work must be tracked on both sides.

Example:

• Team A is process owner of process A that is implemented by a Jira workflow.
• Team B has to process a task that is part of process A.
  • Team A starts process A (tasks 1, 2, 3), Team B receives a task (task 4), after finishing Team A finalizes process (task 5, task 6).

Ideas:

• Work with security levels:
  • Team B gets access to Team A's project but just can see tickets with a specific security level.
  • Not preferred as there might be multiple correlations in both directions (or more as more teams share processes).
• Work with portal view:
  • Team A is process owner and task 4 can be viewd and be done by Team B as customer in the portal view. Comments and information can be shared.
  • Works in another instance, but the task is not shown on any report (or queue/board) of Team B and cannot be tracked therefore.
• Work with multiple issues:
  • An issue is created in Team B's project.
  • Can be tracked but there is not Jira issue that can be seen by both so now collaboration (comments etc.) is possible.
    • Could be done through workarounds as automations that clone comments. But much technical effort.

Do you have any other ideas what could be a practical solution?

[Matthias Gaiser _K15t_ · Accepted solution]

Hey @MarcSch

that's an interesting scenario which you describe. I'll add some of my thoughts to your ideas to develop them further:

1. Work with security levels
   If you go that path, you could also think about such a setup:
   • Create a custom (multi-)group picker field which stores which groups should see a ticket
   • Setup a security scheme with one security level and add as members the Team A as well as the group picker field configured before.
   • With this setup you can simply add a group to the multi picker field and they'd be able to view this ticket.
2. Work with portal view
   This approach somehow works, but I'd discourage it because it mixes customers and departments.
3. Work with multiple issues
   That's the clearest option to actually separate concerns, e.g. Team B doesn't need to know about the tasks 1,2,3. It requires some effort to setup an automation or a sync tool or similar, but depending on your requirements it can also be quite simple.
   • I'd enable some comment sync, a simple Jira automation could do the trick to copy every comment from one issue to the other.
   • I'd also add some automation based on the status, so if Team B is finished that the ticket of Team A gets updated with a comment/status change, etc.
   • Instead of automation, you could also use an issue sync app and configure it accordingly so that it synchronizes the ticket to Team B as soon as it matches some condition.

Please note that with the first solution, you only have the option to share the whole ticket or nothing. This gets more selective if you setup an automation or use another app to exchange exactly what you need/want.

I hope my thoughts help a bit in finding a solution.

Cheers,
Matthias.

PS: Please note that I'm part of the team behind Backbone Issue Sync. If you want to follow the path to use an issue sync app, we're happy to guide you in the process. Let us know via help@k15t.com.

[MarcSch]

Hi Matthias,

thanks for sharing your thoughts. Regarding option 2 this is currently a workaround for us as not all teams work with Jira, but as you said no option in the long-term.

Good hints regarding optiosn 1 & 3, in our view depending on the team constraints (what may the other team see - the whole process or just its tasks) which one is the best.

We will discuss and compare the options in a demo setup.

Regards

Marc 

[Dhiren Notani_Exalate_]

Hi @MarcSch ,

This is Dhiren from Team Exalate.

I would recommend you creating an integration and sync issues between multiple Jira projects. If you are open to use a 3rd Party Integration tool for this, then I would like to introduce you to Exalate.

Exalate, provides a fully bi-directional synchronization between Jira(Cloud,Server,Data Center) and Jira(Cloud,Server,Data Center) among other ITSM systems that is fully customizable. It is easy to set up and the entire customization can be configured using a no-code interface. It also provides a Groovy based scripting engine for limitless customizability.

You can even integrate between Jira Software, Jira Service Management (Service Desk) and sync issues inside projects back and forth to achieve your integration requirements.

Exalate provides a flexible synchronization engine such that issues are automatically and securely synced - between multiple Jira's - wherever hosted. Benefit from a unified view and integrated workflow!

Use cases supported:

• Service Desk to Service Desk
• Service Desk to Software
• Agile Board Cooperation
• Ticket Tunnels
• Information Consolidation
• Centralized Master Instance
• Migration
• Support and development

If you would like to see a customized demo of the product in action, feel free to book a slot with us. 

Thanks
Dhiren

[MarcSch]

Hi @Dhiren Notani_Exalate_ 

thanks for your recommendation. Currently we are not open to use a 3rd party tool. Therefore we will start a test implementation using Security Levels.

Regards

Marc

[Diana_Architect_ZigiWave]

@MarcSch hello! I see Matthias has shared some pretty good ideas to try out. In case you'd like to try the option of syncing the instances, I'd like to add another one: ZigiOps. It's a no-code solution that can help you connect the systems and sync them immediately. You choose the type of data you want to transfer and synchronize (+ who can make and who can see the changes made)  - projects, comments, and tickets are kept up to date in real time. Feel free to look at it and if you want to explore ZigiOps capabilities further - you can book a meeting so we could get a deeper look at your use case (and any related questions regarding it).

Regards, Diana (ZigiWave team)

[MarcSch]

Hi @Diana_Architect_ZigiWave 

thanks for your recommendation. Currently we are not open to use a 3rd party tool. Therefore we will start a test implementation using Security Levels.

Regards

Marc