What is the best practice to escalate a ticket to another service project?

[Bill Thang]

Hello,

I currently have a use case where end users in Asia will report issues through our service desk project “Asia System Support” (AST). Then we will provide an initial assessment of the ticket to see whether it is a bug, enhancement, or incident and if it is needed to be escalated to our headquarters in Germany. If we need to escalate to Germany, there will have to be a ticket in the respective project.

The problem here is that each of these projects have their own required fields to fill in and I do not know the most efficient way to transfer/escalate the ticket to another service project.

Here are some of the options I have seen and their cons:

1. Create a linked issue to the original ticket: when I do this, all of the required fields of the service desk did not appear —> information will still be missed when we create the new ticket for Germany team.

2. Move the original ticket to the responsible service project: same issue with the 1st option where information fields will be missing in the new ticket and the Asia team will not be able to track the amount of tickets issued in our project + workload of our agents in the Asia project

3. Manually create tickets in the respective service project iin Germany and link it to the original ticket: while this does ensure that the new ticket has all the info field filled in and tracking ability in the Asia project, there are too many manual steps & copy paste of information which is not ideal when we will have to process hundreds of tickets.

So the question here is, are there any other methods that will ensure the adequacy of information in the new ticket, tracking ability in Asia’s project, and efficiency (least manual steps possible) when we escalate/move a ticket to another service desk project?

this is the create linked issue view, I cannot edit which field to include.

Thank you!

Bill.

[Walter Buggenhout · Accepted solution]

Hi @Bill Thang,

Let me start by stating what you should not do: move the original ticket. Apart from other settings, JSM projects tend to have different access settings. Moving a ticket to a different project usually means it disappears for the customer, which means you lose the line of communication with your customer. That is something you want to avoid.

So, creating a linked ticket is the feasible option. That means: collaboration across multiple teams. If you say the Germany team has required fields for ticket creation, you'll have to make sure you either:

• make sure you fill out those required fields on your ticket prior to escalating the issue to them;
• or if that is not possible, discuss with them how you can set up a new process (e.g. through a new issuetype, a modified process, ...) where you can work around that.

You could consider using automation to create the linked issue (there is a clone issue action available to copy a ticket and even set additional fields while doing so).

An additional benefit is that you can use automation to sync status updates across later on in the process to keep your original ticket updated when the status of the newly created issue changes.

Hope this helps! 

[Bill Thang]

Hi @Walter Buggenhout , thank you for your reply. Yes I agree, moving a ticket is not a good option.

Filling in the required fields on my ticket prior to escalating it to the team would also be a good option here, I will discuss these options again with the stakeholders.

Once again, thanks for your input!

[Syed Majid Hassan -Exalate-]

Hi Bill,

This is Majid @ Exalate. 

I think Option 1 that you mentioned is very feasible, but the step that you are missing here is Jira automations. If you couple the automations with the linked issues, you should be able to get a feasible solution here. 

If you would rather "outsource" the problem totally, an issue synchronization solution like Exalate, would be the answer here. Set up a local sync the target project, set up the custom field mappings and rules for mandatory fields, and it is all done!

Please let me know your thoughts and I would be happy to assist if I can. 

Thanks

Majid

[Katarzyna Szumilas_Deviniti_]

Hi @Bill Thang

Have you considered using a 3rd party synchronization app?

My team recently released a free, cloud solution called Issue Sync Lite, that seems to fit that use case perfectly. You can set it up to automatically create issues in project for the German team when the issue in "Asia System Support" project is escalated or changes its issue type.
The plugin will copy over fields, comments, and attachments and will keep both issues in sync also when their values change. 

You mentioned that having different fields' sets between projects is a challenge - with Issue Sync you can copy the data from desired fields from the support ticket to any text fields in the software project. Thanks to that the data won't be lost.
Also, synchronizing instead of moving issues will help both teams stay informed.

If that sounds like a potential solution, feel free to test the app or book a free demo with our team.

Best regards,
Kasia from Deviniti

[saifullah saif]

My team recently released a free, cloud solution called , that seems to fit that use case perfectly. You can set it up to automatically create issues in project for the German team when the issue in "Asia System Support" project is escalated or changes its issue type.
The plugin will copy over fields, comments, and attachments and will keep both issues in sync also when their values change. 

[Bill Thang]

This is the view when I create a linked issue, I cannot edit the which field to appear in the create view

[Matthias Gaiser _K15t_]

@Bill Thang - there's no easy straightforward way to add fields to the create linked issues screen and here's the corresponding feature request to watch/vote for.

But I was able to find this workaround description how you can still add fields to the linked issue screen. You need to mark them as required in the field configuration, then they'll show up on the create linked issue screen.

For the other solutions, I have two questions which are key for me to select the best option for you:

1. Do you have the need to keep both issues in sync after the creation?
2. Do you have all the information for the German issue already in the Asian issue?

Cheers,
Matthias.

[Bill Thang]

Hello @Matthias Gaiser _K15t_ , unfortunately I can't configure the linked issue screen because I'm not a jira admin, just a project admin

to answer your questions:

1. I do not need to keep them exactly in sync since the workflow of the 2 projects are different but it would be great if any updates from the second ticket will be communicated to the 1st ticket
2. Currently, no. the Asian issue has 3-4 fields while the Germany issues have from 10 -15

[Luka Hummel - codefortynine]

Hi @Bill Thang

I'm Luka from codefortynine and if you don't mind using a third-party tool our app Deep Clone for Jira could help you make that process really easy.

Deep Clone can clone the issues needing to be escalated via Single Clone to the HQ project with all its field values and you can even add or change data in fields while cloning with our Clone and Edit feature. This might be useful if you have fields requiring filling in your HQ project that isn't filled in the Asia project.

You can even create a preset for your agents in the Asia project so there is an "Escalate" preset available in the Actions Menu ··· of your issues.