This Expert View Article describes how Jira Service Management can be configured to allow task sharing between Service Projects while maintaining confidentiality.
Jira Service Management is growing!
Jira Service Management (JSM) makes it easy for any business unit to make its goods or services available to employees and customers with an intuitive user portal in a common channel. Organisations are steadily increasing the number of Jira Service Management projects that they offer. Expanding from traditional IT Service Desk offerings, there are now a growing number of templates and use cases for HR, Payroll, Facilities, Marketing, Legal and more.
Many business processes need actions or input from multiple business units. Some interactions can be automated, but there are still instances where teams will need to work together. The most well known and common shared process would be a Joiner journey. In this for example, there would be tasks needed from JSM projects in Payroll, HR and IT.
What’s the challenge?
Without configuration, JSM agents will not be able to collaborate with other JSM projects effectively.
Even when each of these teams are using JSM, they are usually set up with separate projects and permissions that don’t allow agents from each project to interact with each other.
What are the options for sharing?
EXAMPLE: Let’s consider an IT team that needs to raise a ticket to the HR team
| Sharing Method | Description | Pros & Cons |
| Portal | IT can raise a ticket with HR on their JSM Portal. | Only the reporter is able to see the ticket, not other IT team members. If you raise on behalf of another user the IT team will lose visibility of the ticket. Requires agents to context switch between the full featured agent view and the portal views. |
| Organisations | Add the IT team to an organisation that can view each other’s tickets. | Users can only be part of one organisation but the IT team can now see and interact with issues other members of the IT team have raised, but they need to do it via the Portal. Still requires agents to context switch between the agent and portal views. Via the Portal the IT team would be unable to:Link issues Modify reporterMake internal commentsJoin multiple orgs |
| Request Participants | Add members of the IT team to the issue as Request Participants | Unable to add a group to request participants. Could be a high number of team members to add. No reason for everyone in the team to receive all notifications for the ticket. |
| Service Desk Team Role | Add the group containing the IT team to the ‘Service Desk Team’ role in the HR project. | This now allows IT to have an agent view of tickets in the HR project, however this now gives IT too much access. They’d be able to edit, schedule, progress workflow and resolve issues in a project that they don’t own. |
| Custom Role | Add the group containing the IT team to a custom role ‘External Team’ in the HR project. | Provides agent access to the issue but can be configured with limited permissions. |
By using a custom role, the IT team with a role of ‘External Team’ can more effectively collaborate with HR. The whole team is able to create, view and interact with issues they’ve raised in the HR project but they’ll be restricted from actions HR wouldn’t wish them to take, like editing field data or progressing workflow.
What about confidentiality?
When providing other service teams with an ‘External Team’ role in your project, you’ll be granting the Browse permission, which will by default give them access to see ALL ISSUES in your project.
For scenarios where both teams are trusted with the data in the project this is not an issue.
In our earlier example, it would not be appropriate for IT to view all issues in the HR project as it’ll contain personal and confidential information that is not relevant to IT.
To remedy this we need to ensure that Issue Security is set up in the project so that agents from other projects that are assigned a role of ‘External Team’ are only able to see the tickets relevant to them.
A table of example Security Levels are below:
| Security Level | Users / Groups / Roles |
| This project only (default) | Visible only to users with a role ‘Service Desk Team’ |
| Shared with External Teams | Shared with anyone in the current project assigned a role of ‘External Team’ |
| Shared with IT Only | Shared only with members that have a role of ‘External Team’ and are a member of the group ‘IT’. |
| Shared with Legal Only | Shared only with members that have a role of ‘External Team’ and are a member of the group ‘Legal’. |
NOTE: You may need to apply ‘This Project Only’ to all tickets in the project as issues that have no Security Level applied will be visible to everyone with Browse access.
How do we make it easy for users?
To reduce the likelihood of user error, applying the appropriate Security Level can be automated. The method will depend on your use case and workflow but some examples are below:
Workflow
Add a post function to assign an appropriate Security Level based on the role of the user raising the issue.rn
Request Type
Add the Security field to the Request Type as a hidden field. When raised by an agent the value will be defaulted to this.
Automation Rule
Create a rule that checks the group membership of the current user and applies the appropriate security level
Conclusion
By configuring custom roles and security levels we can create an environment where service projects can collaborate effectively and easily. This is a method that I have found that works well for our customers.
An on-demand demonstration of this will be presented at Atlassian Team ‘23! Don’t miss out and add it to your calendar here .
If you have an alternative or would like to speak to us about how Devoteam can help your organisation collaborate more effectively please contact us.
About Devoteam A Cloud
With 500 clients across Europe, Devoteam A Cloud offers excellent know-how on AWS technologies since 2012. Our team of 550+ AWS experts supports customers with scalable infrastructure, new ways of thinking and operating enabled by AWS so that they can explore new possibilities, re-invent their business, and evolve into an enterprise platform.
Devoteam is an Atlassian Platinum Solution Partner, we have passed the strictest training requirements and have a tried-and-true business model that can scale from serving small to very large clients. We are well equipped to manage a variety of customer solutions and have an established run rate of Atlassian business. With a team of Global Certified Individuals, we try to improve our and your business as much as possible. We try to provide amazing products and services tailored for your team.
David Meredith
Senior IT Service Management Consultant
Devoteam UK