Service Desk Automation - Setting Assignee To Service Desk Team Member Who Escalated to Dev

[JD Lobue]

What is the best way to set an assignee back to the service desk team member who escalated to development? I don't see a post function that allows me to select change assignee based on who set a custom field. Has anyone done this, or can anyone lead me in the right direction?

Thank you

[Jack Brickey · Accepted solution]

Here is a suggestion to try...

• create a user picker custom field called "Escalated by" and have the escalator set to their name when they escalate. you could consider automating this, copying the current assignee in but if they change the assignee before escalation then that would fail. something to investigate.
• use a transition to move it back to the escalator copying the value in the "Escalated by" field.

I have not done this but I think it should work out for you.

[JD Lobue]

Thanks for your response. The idea would be to not have to have additional steps for the service desk to have to make and to use the current assignee that set the custom field upon escalation and not have to have them enter a separate field. How can that be done?

[Jack Brickey]

JD, there really is a good bit of detail missing that makes it hard to give you the 'best' answer but I will try and frame it up w/ the assumptions and conditions that are in my head. If i had an image of your current WF and a bit more details. Again this all depends on how you want to solve it and my answer is how I would approach based upon my assumptions.

If your developers are JSD agents and will take ownership of the specific JSD issue then do this....

1. Create a custom field called Escalated By of type user picker
2. Create a status called Escalated with a transition into it called Escalate
3. I would add a post function to the Escalate transition that would copy the current Assignee into the Escalated By field
4. I would add a post function to the Escalate transition that would clear current assignee to Unassigned.
5. I would create a queue called Escalated Triage where all issues in the Escalated status AND Unassigned would land
6. I would have my escalation team (development) be accountable for monitoring the Escalated Triage queue and take ownership and set the assignee. You can setup notifications for this as well obviously.
7. I would have a transition out of Escalated into whatever the appropriate status is. In that transition I would add a post function to copy the Escalated By value into the Assignee.

If your developers are not agents but rather your JSD agents escalate thru JSW by opening up a JSW issue then do this...

1. Leave the original JSD issue assigned to the JSD agent
2. Create a status called Development and a transition called Move To DEV
3. The agent creates a linked issue from JSD to JSW
4. Setup Automation to have the JSD issue to automatically move to Done once the JSW issue moves to Done.

[JD Lobue]

This very much akin to what I'm thinking. I want to automate it rather than using transitions, however. Thanks a bunch for your step by step details. Really appreciated.

[Jack Brickey]

Agree that automation would be wise. I use Automation for Jira as Cody mentioned and it is quite powerful. If your requirements are such that it results in less than 300 per month the you can go with free. I recommend you install the free version and play with it and get a feel for it. Their documentation is quit good too but the basics are intuitive. 

[Cody Stevens · Accepted solution]

To expand off of what Jack said, you can use a app called Automation for Jira Cloud. This is an incredible tool for automation. 

You could use this to do exactly what Jack said but automated. They have a paid and free version. For your convience, both are linked below! If you use the free version, they do limit how many automations you can run a month. 

Paid

Free

[Cody Stevens]

Also, you can look into ScriptRunner. They may be able to do this as well inside the workflow itself but I'm not super familiar with their app. 

[JD Lobue]

Cody, we are using Automation, and I'm trying to figure out how to use it. Can you assist? I have the same ideas as Jack mentioned above. Just want to understand how to use Automation correctly.

[Cody Stevens]

Hey JD,

As Jack said, you can use the free version. Its incredibly powerful and I was using the free version for months before we upgraded. 

I can't exactly say how I would do it with Automation for Jira because I don't know how the escalation works on your end. It sounds like it's just reassigning the issue and you want it to go back down the chain.

Assuming that everything stays in the one ticket and nothing additional is created, you would still want to create the escalated by field (user picker) and then you would use AFJ to do the following. 

Automation 1

1. Set the trigger to Issue Transitioned
2. Select the statues you made for the escalation for the To Status section
3. Add a new action and use Edit Issue
4. Select the Escalated By field and change it from Set Value to Copy From         (Below screenshot for example)
5. Then change the field you are copying from to the Assignee field
6. If you are reassigning here or doing anything else, do it in this section
7. Create the automation and give it a name 

Automation 2

You will need to make a second automation for when the issue is deescalated.

1. Set the trigger to Issue Transitioned
2. Make/select the statues you made for the descalation for the To Status section
3. Add a new action and use Edit Issue 
4. Select the Assignee field and change it from Set Value to Copy From 
5. Change the field it's copying from to the Escalated By Field. (screenshot for example)
6. If you want any actions to take place, add them here 
7. Create the automation and give it a name

To recap, the first automation is run when the issue is escalated. This will copy the current assignee into a user picker called Escalated By. If the issue is deescalated, that will trigger automation 2 which copies the escalated by field into the assignee field. 

[JD Lobue]

These are great. Thanks a bunch for your guidance along the way. I don't see issue transitioned as one of the selections. I have these:

- a linked issue is transitioned

- Approval Complete

- Approval Required

- Comment Added

- Issue Created

- Issue Resolution changed

- Organization added to issue

- Participant added to issue

- SLA time remaining

- Status changed

- Time in Status

I want to use a seperate custom field we created (Support Tier) to trigger the copy to escalated by custom field. Can that be done using any of those above?

[Cody Stevens]

The list you provided is from the out of the box automation. The guide I provided was using Automation For Jira Cloud. I dont think what you want done can be achieved using the regular automation. I would test out the free version of the Automation for Jira app which is linked in a previous comment.

I am confused on the "Support Tier" field. You want to copy the value from that field into the Escalated by field? Or you want the automation to run when that field is populated? 

[JD Lobue]

The latter. The support tier custom field is used when our support desk needs to escalate to one of our dev teams. So, I would like to copy the assignee field into the escalated by custom field once that Support tier field is changed from EMPTY to Some value.

[Cody Stevens]

You definitely can't do that with OOTB automation. In AFJ you can though! 

Attached is a screenshot to make this easier to understand but you would do the following.

You can skip steps 1 and 2 in the Automation 1 and do these steps instead

1. Instead of using the trigger, Issue Transitioned you would use Field value changed
2. You would select the field Support Tier 
3. Then add a compare condition 
4. For the first field, input {{issue.customfield_IDNUMBER}} replace IDNUMBER with the custom field ID
   You can get this ID by going to the custom fields section in Jira Settings < Issues < Custom Fields
   Find the custom field and select Edit
   The ID will be at the end of the URL 
5. Once you have the ID and the first part filled out, set the condition to Does not equal
6. Leave the second value empty.
7. Continue with steps 3-7 in automation 1

[JD Lobue]

Do I care about the compare values? The tier is not being changed again once development is complete. A new status would trigger the assignee back to the one who set the support tier?

This is what I got in the log for the rule:

Action details:

Edit issue

Tried to copy value but fields are incompatible

customfield_10190 : customfield_10190

Issues edited successfully

Any ideas? The custom field is a user picker for all issue types. I don't have it available on any screens because I want it hidden. Do I need to configure the custom field in any way for compatibilities sake?

[Cody Stevens]

The if condition is a failsafe so the automation doesn't accidentally run. I recommend keeping it. 

From the error you provided, it looks like the field may have been inputted incorrectly. Do you have it in the below format? 

{{issue.customfield_10190}} 

If not please change it to that, if you do can you please take a screenshot of the if condition and the audit log? 

[JD Lobue]

[JD Lobue]

[Cody Stevens]

Ah, that's your problem! It needs to be exactly {{issue.customfield_10190}}. You have the cf before the number.

[JD Lobue]

I found the error. I had the value pulling from escalated by and not from assignee. Thanks for all your help. What if I want to allow the support tier to be able to move from one escalation dept. to another? Can I change the condition to allow for that?

[Cody Stevens]

This automation will run every time the Support Tier field is changed. So if I understand the process right, the "Support Tier" field is a custom user picker. If someone wants to escalate the issue, they will select a user from that field? That would then trigger the automation to take the user from the field and make them the assignee. 

Did I understand that correctly? 

If so, its already set up to handle that. Each time someone edits the Support Tier field, the automation will do its job. 

[JD Lobue]

support tier is a custom picker with tier values (Tier 1, Tier 2, Tier 3) and each tier can be used once support escalates. Tier 1 may need to push to Tier 2, and maybe to Tier 3. No user is selected. If support goes to tier 1, a dev in tier 1 is assigned, then changes to tier 2, currently the escalated by is updating to the dev in Tier 1. I need it to stay with the Support engineer who initially escalated to tier 1.

[Cody Stevens]

It can do pretty much anything you can imagine. To achieve that you would use the condition If else Block. You would add the conditions and actions under the first block and you would add a jql saying Support Tier = Tier 1 or a compare condition for {{issue.customfield_10190}} equals Tier 1. 

Then add and else and do the same stuff but change the Tier 1 to Tier 2 and then change who the assignee is.

Then again for tier 3.