Escalation JSM project to another JSM with automation

[Julien Verdier]

Hello,

Here is our use case: 

Two teams A and B are working on 2 different but identical JSMs (same workflow, same Custom Fields etc...)
Team A needs to escalate issues to B

Ideally, team A should use a Status such as "Escalated", an automation transfers the ticket to team B with all the details present in the initial ticket. Just like when we use the "Move" action on an issue.

The problem is: 

1. The request type cannot be copied with the automation of the A Project (but this can be solved by adding the request type from project B with an automation)
   1. If the request type is not specified, the user who opened the ticket will not see it on the portal once the ticket is escalated
2. Comments are not copied (we lose the history)
3. We lose the date information (the creation date)

My question here is:
Is it possible to use an automation to activate the 'move' option on an issue? 

Thanks

[Nic Brough -Adaptavist-]

Welcome to the Atlassian Community!

This doesn't work because you should not be moving requests from one project to another.  To many of your customers, this would look like you have deleted their request because they can't see it in the other portal.

Two options for handling it though, quite easy with a bit of config:

• Duplicate the issue into the escalated project.  You'll be able to automate most of the copying of data, and you won't be destroying the request for the customer.
• Better, amend the queue that the team receiving will be working from, and put something on the issue that allows the queue to select escalated issues

[Patrick Haley]

@Nic Brough -Adaptavist-  can you please elaborate on your second suggestion? I'm curious how this would work.

[Curt Holley]

The simplest solution here is to have your "escalated" status in Project A, set up a queue showing only the escalated tickets (in project A). Allow the already licensed agents (or a subset of) access into Project A so they can work on them there. 
Thus retaining all data gathered within and ability to communicate with the customer.

Then just focus on what other tricks that "escalated" status might require (via , conditions, validations, post functions or automation) to assist inform, control and report on these escalated tickets.

[Jimi Wikman]

In Theory you can add a custom field called "Escalated" to act as an anchor between the two projects.

When the ticket is escalated you set an automation to check the escalated box and then you can create a Que in the second team that fetches all ticket with the Escalated checkbox.

This way, you can have the same ticket exist in two projects at the same time and you can work on the ticket as normal and see all activities from both projects.

This is how I set up development that include integrations where you need work to be done on both sides. I have not tried it in JSM yet, but I can see how this could be useful to trigger escalation to second line, for example.