How to manage multiple service desks in Jira Service Desk

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.

Technical measures

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.

Creation

This is an operation with a fairly traditional configuration. If you want to see the documentation for it, it’s right here.

Synchronization

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.

Script Listener

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.