Making the choice to work with Jira Service Desk helps minimize ticket processing time while improving the quality of responses. Because these advantages are inherently appealing, there is a direct impact on the number of teams that want to use it, and therefore indirectly affects the number of service desk projects on a single Jira instance. If we take into account the versatility of some agents who serve on multiple teams, the following paradox emerges over time: the more an agent works on different service desk projects, the less efficient she will be.
The explanation for this phenomenon is fairly obvious; currently, Jira Service Desk does not offer an interface that combines every ticket, thus preventing an agent from having access to everything in a single view. The agent therefore needs to switch from one project to another in order to see the ticket queues assigned to each project. In some extreme cases, this complicated user experience leads agents to give up and go back to a traditional Jira dashboard, depriving them of one of the key features of Jira Service Desk: its interface for agents.
But there are solutions!
In this article, we’ll see the use case in which Valiantys encountered this problem and how we worked around it. For interested readers, the second part will also cover more technical details on the solution as well as a few alternative work-arounds.
Valiantys’ support architecture
As an Atlassian Platinum Solution Partner, Valiantys offers a support plan for Atlassian products. Like many clients, we have chosen Jira Service Desk to optimize this activity as much as possible. Our support team therefore uses Jira Service Desk each day through a central project named Valiantys Support (VS).
As our support plan evolved to offer “unlimited” contracts, we needed to create new support projects which were each fully dedicated to one client. This left us in the situation where our agents were required work on multiple service desk projects.
Let’s look at an example support project for a client on an “unlimited” contract, named Client Support (CS), which is of course a service desk project. In this case, we have issues that are created in both projects, but we must also prioritize them in order to adhere to all the SLAs in place. With a single CS project, it was possible to keep working by switching between the two support projects. But with a nearly constant increase in the number of projects similar to the CS project, we were getting dangerously close to the support team losing productivity.
Synchronizing issues between two Jira Service Desk projects
In order for agents to avoid switching between projects, the queues of the main project (VS) needed to be able to show issues that are in another project (CS) on the same screen. However, Jira Service Desk does not make it possible to include issues from other projects in its queues:
Based on this observation, the syncing-based solution was the natural choice. Whenever an issue is created in a CS project, an equivalent issue is automatically created in the VS project. Afterward, we synchronized each update made to the CS issue in the corresponding issue within the VS project, giving us a consistent view. Here’s what it looks like:
Now that the issue has been created, here’s what the agents see in the VS project:
Note the presence of both keys: CS and VS.
In order to not disrupt the client with multiple reference keys, all the work is done in the CS issue: transitions, comments, reports, etc. The VS issue exists only to give a view of the key aspects of the original issue. Here is what an agent sees when she clicks on each key:
Thanks to syncing, we have therefore centralized all issues related to the support activity into a single service desk project. The only notable difference for agents when they work on synced issues is that they need to do so on the CS issue, not the VS issue.
Now let’s see the technical measures put in place to achieve this result.
Two apps are used to manage syncing.
Exocet: Automate the creation of linked tickets
Exocet makes it possible to automatically create a VS issue when an issue is created in CS. While doing so, it also links the two issues to one another. This link adds visibility while also synchronizing the issues’ fields.
Mapping the fields
In this section, the fields are matched to the future linked issues. Nothing special to mention for the configuration. The documentation can be found here.
This is an operation with a fairly traditional configuration. If you want to see the documentation for it, it’s right here.
Finally, synchronization is configured as follows. For more information, see here.
Script Runner: Sync the transitions using Groovy scripts
We use Script Runner in order to manage the syncing of transitions, display dynamic fields in issues, and configure scripted conditions on transitions.
Here is the Script Listener we used:
This Script Listener listens for transitions that took place on CS issues, and replicates them on the corresponding VS issues. We use a “robot” user to perform these transitions.
The scripted fields
Two Scripted Fields are used in the use case presented in this article:
- The Sync Key field, which makes it possible to display the CS reference in the VS ticket, particularly as a column in the queues:
The way it works is fairly simple; it searches issues related to the VS issue for the one that uses the link mentioned in the Exocet configuration. What it returns is simply a (clickable) link to that issue.
- The Synchronized Issue field, which is used to display a warning message:
Same principle as the previous field, but this time we add a defined form and display this field in the issue.
Finally, the transitions of our workflow are defined by conditions so they are not displayed in the VS issue if it is linked to a CS issue. To do so, we use a Simple Scripted Condition (on each transition).
The transitions are displayed only if the returned value is “true”.
Alternative: Syncing transitions with the Automation module of Jira Service Desk
It is possible to sync the transitions in Script Listener. For example, one may use the Automation module of Jira Service Desk. This makes it possible to run a transition on an issue of the service desk project when a linked issue was also transitioned.
Valiantys chose syncing because it’s the most reliable and flexible solution for our support needs. Nonetheless, other solutions exist, which might be suitable for other cases.
Recently launched on the Atlassian Marketplace, Queues makes it possible to incorporate issues from other projects into a service desk project’s queues. Although this app addresses the issue presented in this article, it has some limitations: For example, it cannot display all field types that you want in the columns. Queues actually replaces the traditional display of Jira Service Desk queues.
A final word
Jira Service Desk is being increasingly adopted by teams. It is therefore very likely that you’ll be faced with this problem one day. Nonetheless, you have everything it takes to offer your teams the best solution for their needs.
And if you ever need a hand to address this challenge, feel free to call one of our consultants, who will be happy to help you implement this solution!