JSM implementation case study: request escalation and transfer

In this article, we talk about escalating and transferring support requests to other teams using JSM.

Remember, in previous articles in this series, we looked together at how we had set up several technical and business support projects with Jira Service Management (JSM) at my customer's site:

  • First of all, we thought about how Jira would be used in their context. Then the choice of a flexible and adaptable solution to meet their different needs;
  • Then the addition of automatic routing of requests to the right helpdesk.

I now propose to introduce two new mechanisms to enable assistance teams :

  • Escalate a request for assistance to a level 2 team;
  • Transfer a support request to another support team.

In this article, we'll look in detail at the implementation of the solution adopted for request escalation. Transfer will not be discussed in detail, as the parameterization is very similar to escalation.

As a reminder, my client uses the following plugins:  

  • Script Runner ;
  • Automation for Jira (included in Jira Software and Jira Service Management Data Center) ;
  • Assets - ex Insight (included in version 4.15 of Jira Service Management Data Center).

This is a fairly technical article, as we'll be writing new Groovy scripts.

Climbing, transferring or both?

Here's an example of a successful transfer.

Before we begin, I would like to clarify the difference between the two terms used by my customer:

  • In the case of escalation, the agent asks for help from another team, known as "level 2", which has the skills and knowledge required to resolve the request. This might be a software development team, for example, which is able to correct an anomaly detected by a user. During escalation, the agent retains control of the user's request: he remains his privileged interlocutor, and the user does not see "what's happening" on the development team side. It is the agent who will act as the link between the level 2 team and the user, if necessary;
  • In the case of transfer, the agent sends the support request to another support team who will take over. This may be necessary, for example, if the user has used the wrong channel to report the problem, and the request has fallen to the wrong team. During the handover, the agent hands over responsibility for processing the request to the other team. He no longer follows it up. The new support team in charge of the request exchanges directly with the user.

Escalation to the IT department: the need

The three support teams needed to be able to escalate requests to the application teams on the IT department side:

  • The Strawberry and Pineapple teams wanted the target team to be automatically deducted according to the qualification of the request. For example, if the request concerns the SUPERAPP application, then the request should be escalated to the team in charge of the SUPERAPP application;
  • The Apple team wanted to be autonomous in choosing which team to escalate the request to, from a very specific list.

The Strawberry team also needed to be able to specify to the target team a list of actions expected during the escalation.

Finally, all three teams wanted assistance requests to be in a dedicated state following escalation, so that they could be easily isolated. The support request would then automatically return to a given state when the escalated request was resolved. In this way, the support team would know that it could regain control.

On the end-user side, depending on the situation, this stage may or may not be completely transparent.

Level 2 teams needed access to the context of the support request, visibility of exchanges with the end-user, and knowledge of the agent in charge of the support request so they could contact him or her when necessary.

Transfer between support teams: the need

The Apple team specializes in technical assistance and equipment management. The Strawberry team specializes in business support and expertise. It's not uncommon for a user to make a request to the wrong channel, and for it to fall to the Strawberry team. Whereas the problem concerns the Apple team.

In such cases, the Strawberry team could simply close the user's request, telling him he's made a mistake. But that's not very nice: he's probably already spent some time trying to formalize his request on the problem that's been bothering him all day, and bam, he's told that no, this isn't the right place... and since we don't talk to each other between teams and it's not our place, we have to do it all over again.

Or not.

From a user's point of view, my customer is a single entity. It was therefore important that, in the event of an error, the switchover to another team should be as seamless as possible.

For this reason, each of the two teams needed to be able to easily transfer a request to the other. The transfer had to involve changing the state of the initial request automatically, with an appropriate resolution (to identify them later).

The user also needed to know what was happening. His first request is closed, but another is automatically created for him, with a link to access it.

How to use the standard "Create a linked ticket" functionality

In view of the various requirements, we quickly identified the following solution:

  • Whether transferring or escalating, a new request must be created in the project concerned. There is no question of moving the original request for reasons of subsequent monitoring and analysis;
  • A link must be created between the two applications, the original and the copy.

To meet the general need for team escalation, Jira's editor, Atlassian, proposes to use the standard feature Create a linked ticket.

This feature is available from any support request. It enables you to quickly create a new request in the project of your choice, which will be linked to the original request. When using this feature, a creation screen pre-filled with some information from the original request is displayed to the user, who can then :

  • Select the Jira project in which you wish to create your new request;
  • Select the type of link between the two requests;
  • Adjust the content of initialized fields, such as the summary or description ;
  • Complete the mandatory fields of the target project;
  • Choose whether or not to copy attachments.

On paper, this feature seems to meet many of the needs outlined above, and may even be perfectly functional for some organizations. However, we very quickly identified several bottlenecks to its use in our context, which led us not to opt for this solution:

  • Too many elements are left to the agent's freedom and manual action, which can lead to errors and inconsistencies:
    • The feature does not trigger a status change: the agent must therefore remember to do this after or before copying the request;
    • The target project must be chosen from a list of all the projects to which the agent has access, which can potentially be very long and difficult to read;
    • The agent is free to choose the type of link;
  • Only the mandatory fields of the target project are proposed in the form: the agent cannot complete other fields that might have been relevant;
  • Information may be lost, such as comments, custom fields or attachments, if the agent forgets to explicitly check the Copy attachments.

These elements can lead to faulty applications and malfunctions in the set-up. If the status is not properly updated, SLAs, for example, will not be paused or stopped. And if the link type or status is incorrect, the original request will not automatically change status when the copied request is resolved. Finally, if the target project for the escalation is not the right one, this will generate complexity for the teams, as well as wasting time where responsiveness is generally expected.

In short, with "ifs", we cut wood.

So, when in doubt (and in the interests of preserving forests), we opted for a specific solution tailored to our different needs. A technical solution, once again requiring the use of a plugin like Script Runner.

Choice of a customized but controlled solution

The solution therefore consists in setting up different transitions dedicated to each case (transfer, escalation). Each transition enables :

  • Manage the change in status of the request ;
  • Propose a transition screen with additional fields if relevant;
  • Execute a Groovy script that will take care of all operations "under the hood", i.e. :
    • Recover target project for escalation or transfer ;
    • Create a copy of the support request ;
    • Enrich and adapt the data in the application copy, before saving it in the target project;
    • Create a link of the right type between the original request and the copied request;
    • Inform the various stakeholders of the actions carried out.

It's time to get out our best keyboard, our favorite code editor and a thermos of coffee: we're back to coding (well, we've got a few preparatory actions to do first)!

Implementation of escalation of a support request for the Strawberry team

Together, we're going to set up all the parameters needed to perform the escalation and what follows for the Strawberry team. The method is similar for the other support teams.

Prepare the necessary settings

The first step is to prepare in Jira all the elements we'll need to carry out our climb.

We have seen that one of the first things to implement is the deduction of the target escalation project according to the qualification of the assistance request. This value must be able to be overloaded by the agent during escalation. To do this, we need :

  • Identify the escalation Jira project for each relevant helpdesk form;
  • A custom field that brings up the list of Jira projects.

Action 1 - Add the climbing project to service sheets and create a personalized field

We have set up our service sheet repository in theArticle 2. We're going to enrich it so that we can enter a Jira climbing project for each service sheet. To do this, we can simply add a Climbing project type Project. As this attribute is relevant to our three support teams, we add the attribute directly to the parent object type Service support form.

In addition, we create a new Jira custom field of type Project selector (single project) which we call Climbing project. We add this field to the consultation screen of our three support projects.

All that's left is to complete our automatic orientation script set up in thearticle 3 to automatically value the Climbing project from the service card identified for the request.


For the Apple team, who want to be able to manually choose the climbing project from a reduced list, we set up the same field Climbing project without pre-assessment. We combine the use of two plugins to filter the projects proposed in the list:

  • Metadata for Jira, which lets us define a metadata at the Apple assistance project level that contains the list of projects authorized for climbing;
  • Script RunnerBehaviour, which allows us to filter the list of projects proposed in the Climbing project based on metadata.

This method can be useful for organizations that have fewer Jira projects and have no interest in setting up a more complex mechanism for automatically deducing the target Jira project.

To easily isolate and identify escalated requests, we also need a dedicated report, and link types that we'll use to link support requests to requests copied across projects.

Action 2 - Create a status and link specific to climbing

We create a new state Escalade.

We also choose to create a specific link type per support project. In this way, we can have different management rules depending on the type of link, but also make it easier for development teams to identify requests coming from one support team or another.

We therefore call them Transmission Tiller / DSI, Pineapple / DSI transmission and Transmission Apple / DSI.

The Strawberry team also wanted to be able to pass on additional information to the team to which it escalates the request. We already have a free text field Actions expected DSI existing in our Jira instance, which we reuse.


Good practice

Before creating a new "transverse" parameterization element in Jira, i.e. one that can be used by all projects, such as custom fields, reports, resolutions, etc., remember to check that a similar element does not already exist. In the interests of maintainability and performance, it's best to try to limit the number of such elements. And this also enables cross-functionality between projects (for example, a single report In revenue rather than To receive, Recipe in progress, Recipe, In revenue, Recipe by my super PO, ...).

We now have everything we need to set up our climbing transition.

Setting up a transition dedicated to climbing

We need to create and configure our climbing transition. Beforehand, we have created a small transition screen which contains at least the fields :

  • Climbing project
  • Actions expected DSI
  • Attachment 

Important - The " Attachments "

Always, always, always put the field Attachments in each transition screen. Because if this isn't the case, when someone pastes an image into the Commentit will get a mini error message (Adding attachments is not supported for this screen.) disappearing faster than it appeared, indicating that the file could not be loaded. That's right, because the Attachments is not in the form. If she hasn't had a chance to see the message - the most common case - she won't understand why her image has been replaced by a broken visual.


Action 3 - Creating and setting transitions

We create a new transition Climbing the ISD which starts from the "In progress" state and goes to the Escalade. We associate it with our transition screen, and configure a validator to render the field Climbing project mandatory.

As a complement, we are adding two additional transitions that will allow agents to avoid being blocked in certain special cases:

  • A transition Return to coursewhich allows you to return from the Escalade in state In progress manually ;
  • A transition Link to an existing DSI requestwhich allows you to switch to the Escalade without copying the support request. In this way, if an IT department request already exists for the problem encountered, the agent does not duplicate it and can directly link his support request to it.

The escalation transition is ready. We now need to set up the script that will perform all the operations of copying, updating data, etc. The script is a Post functionwhich, as its name suggests, is placed after the transition. To find out more about this type of script, please consult the editor's documentation: Post Functions Tutorial (adaptavist.com).

Action 4 - Add a Post function script

We start by importing the classes we'll need, and declaring the various constants we'll use in the script.

Then we initialize the Jira Java API services we'll need, and retrieve the necessary custom fields.

We then retrieve the data for the project into which we're going to copy the request: the project key, using the Climbing projectIt also has its own specific settings, i.e. its default request type and default request manager.

We're ready to go: we make a technical copy of the request. In order to retain as much information as possible, we use the complete copy method, with all fields. It is then necessary to reset a few fields, such as the creation date, time estimates, etc.

This is an opportunity to highlight our target project. We prefix the request summary with the words CLIMBING. We choose to position the agent performing the escalation as the reporter of the copied request: in this way, it will be notified and informed when the copied request evolves.

The Strawberry team wanted to pass on information to the DSI team during the escalation. The agent can use the Actions expected DSI for this purpose. We therefore need to retrieve the content and concatenate it with the request description. This will make it easier for the IT team to read and take into account. It will also save us having to add the field Actions expected DSI in the consultation screens of all projects eligible for escalation.

We finalize the creation of our new request, which allows us to :

  • Add the link between the original request and the copied request ;
  • Copy attachments to the copied application ;

Feedback to the agent to inform him/her that the climb has been a success: we use a class provided by Jira for this, UserMessageUtilwhich displays a small pop-in with an ephemeral message. The message contains a link to the copied request.

Here we are! The script is in place and the transition is now functional. Make sure you allow agents to create requests in potential escalation projects.


Whether or not to inform the applicant of the escalation of his request

Adding the new state Escalade in our workflow forces us to ask the question: do we want to make this step "visible" to the user on the portal side, or should it be transparent? Depending on the team, the decision was not the same. For one team, we left this step explicit, as is.

For the other two teams, we "hid" this step by using the correspondence screen between the workflow states and the states displayed to the user for each portal form:

Even if the demand changes to Escaladethe user will see no change: the request will always be In process.

JSM vs JSW licenses

There are two types of license in Jira :

  • JSM (Jira Service Management) licenses, which enable users to process requests in projects of the following types Service ;
  • JSW (Jira Software) licenses, which enable users to process requests in projects. Software and use agile tables.

It's good to know that a user, regardless of license, can perform the following actions on any project of any type (as long as he/she has the appropriate authorizations, of course):

  • View requests ;
  • Create a new request ;
  • Submit an internal comment on a request ;
  • Submit attachments to an application.

This means you don't need to give your agents a JSW license to escalate requests to projects. Software and exchange comments in them. And vice versa: you don't need to give a JSM license to your development teams so that they can consult a support request, and possibly post internal comments in it. It's a great way to save money by optimizing your license allocation!

Automate the change of state of the original request when resolving the escalated request

To increase efficiency, we implement an automatic rule that changes the status of the support request when the escalated request is resolved. In this way, the support request returns to the list of requests to be processed.

In concrete terms, the rule must :

  • Trigger when a request linked to a support request with the right type of link switches to a "final" state;
  • Update support request status.

Action 5 - Configure an automatic rule to change the status of the support request

We create a new rule Legacy automation in the Strawberry project. We set it up as follows:

A linked issue is transitioned

- The type of link corresponds to : Transmission Tiller / DS
- Matching requests : status = Climbed
- Correspondence between related requests : statusCategory = Done

Migrate request Resend request Strawberry

We choose to run the rule with a service account that has advanced rights on all projects to avoid errors.


Standard JSM automatic rules or Automation for Jira module?

Since version 9 of Jira, Atlassian has deprecated the standard JSM automatic rules, called Inherited automations. The editor now favors the use of the Automation for Jira. However, using this module today poses two difficulties:

  • Unlike inherited automations, Automation for Jira does not include a trigger. When a linked request changes state. So the logic is reversed: we have to "listen" to all the changes in state of our potential climbing projects, and so use the trigger When a demand changes state on a scope of projects that is very important in our context (we have over 200 potential climbing projects, with a huge number of requests);
  • You must indicate in the trigger When a demand changes state target state(s): it is not possible to use a state category, Done for example. In our case, we still have many final states that we're trying to rationalize as we go along. Listing them explicitly in the rule is therefore not very maintainable.

That's why, for the time being, we've decided to continue using legacy automation.

What about transferring a support request to another support team?

Implementation of the solution for transferring a request remains very similar to that for escalation:

  1. Prepare the necessary settings, i.e. create a specific report and/or resolution to easily identify requests transferred to another team;
  2. Create a transition dedicated to the transfer, for example Transfer to Strawberrywithout manual selection of the target project, since we know it in our case ;
  3. Setting up a script Post-function which manages the copy of the request and the link between the two requests.

In addition, the script should include a public comment on the original request, informing the user that the request has been transferred, and indicating the link to the new request.

Two or three groovy scripts later... The final word

You've made it this far: thank you for your patience and time. I concede that this series of articles is not necessarily good for the headache.

I'd like to take this opportunity to thank my two proofreaders (who will recognize themselves) for their patience, kindness and suggestions. 💖

But after all these steps, we've seen that there are solutions to make the process of requesting assistance as smooth as possible:

  • When it is created, by automatically assigning it to the appropriate support unit;
  • In the event of escalation or transfer, by copying the request "cleanly" in one click to the right project;
  • During processing, by having a maximum amount of information from the moment it is created, and then qualifying it thanks to the Assets repositories.

We have also seen that there are a multitude of solutions for adapting your Jira Service Management to your needs and organization. Sometimes, the standard is enough. But acquiring an all-purpose complementary plugin such as Script Runner can be more than useful and cost-effective, provided you have the skills to make full use of it.

This article is not sponsored by Script Runner. But yes, I have to admit that I really like this plugin and what it offers.

If I had to give one recommendation after a few years working on this subject, it would be tobe patient and do things step by step. There's no magic formula that's going to get it right the first time. Even after 10 brainstorming sessions with the leading experts.

It's through trial and error, more or less successful attempts, improvements and feedback from your users that you'll progress towards the solution that suits you best. What works for my customer may not work for you, or at least not without adaptation. But your tool should be a facilitator for your teams' day-to-day work, not a constraint. So it may be worth spending the time it takes to get there.

Cover illustration by pch.vector on Freepik



Atlassian Consultant


An article by



Atlassian Consultant

Want to go further?