Jira workflow status reverts back after escalation

[Steve Dobrioglo]

Hello there,

I'm troubleshooting an issue where a service desk member escalates a ticket to another group (status) and Jira reverts back to the original status. As you can see from the history screenshot, service desk tech changes status from "Escalated to SQL Admin" to "Escalated to SDI" but then Jira reverts it back to "Escalated to SQL Admin".

• Request type and other fields are set and not empty.
• This happens for one tech only.
• I compared this person's permissions with several other techs who do not experience this issue and they are identical.
• There's no automation that sets status to "Escalated to Admin". It's an initial request submission with selected request type.

I'd appreciate some ideas of what might be happening and where to look for clues.

Thanks much!

-Steve

[Steve Dobrioglo · Accepted solution]

Thank you to all who offered their ideas in trying to solve the issue - much appreciated!

I've found what happens and how to get the issue to transition. First, the issue is not happening only to one user as I initially stated. It happens to me as well and I can see the reverted status wen I refresh the page.

The issue was that issue type had to be changed from "Database Support" to  "Software Support" before escalating (status update). Once the type is changed - it goes through properly.

I'm unclear why it works that way but it could be my limited Jira knowledge. It's not an excuse, of course, but I'm fairly new to Jira administration/customization, doing it part-time when issues arise and the system is inherited. Lots to learn. 

Thank you all!

Regards,

Steve Dobrioglo

[Daniel Ebers]

Hi @Steve Dobrioglo

when you can rule out automation rules for Jira Service Management I could think of some kind of workflow postfunction or REST API integration.

The REST API integration is unlikely in my humble opinion. But you could check if the moment "DEQ Jira" executes the mystical action there is a login of user "DEQ Jira" (you can see it from user management).

At the moment I'd guess it is somehow related to workflow post-function but even for that I am not sure.

Edit: something that now additionally comes to mind would be a Script Listener by Adaptavist Script Runner, I got this idea when re-reading the part of "changing assignee". At least this App has the capability to do what you observe - is it installed in your instance at all?

Regards,
Daniel

[Steve Dobrioglo]

Hi @Daniel Ebers . Thanks for the response and suggestions.

We do not utilize REST API functionality so that is most likely is not the issue, as you've said. Also, no Adaptivist Script Runner application installed on the instance. 

We have only ProForma and Project Automation apps./plugins installed.

As far as post-functions go - this particular transition has a canned post-functions, like other transitions.

The fact that it happens to one user, I suspect permissions but they match to another person's permission who doesn't experience such issue, nor do I as the project administrator. 

Thank you!

Regards,

Steve Dobrioglo

[Daniel Ebers]

That's interesting because ProForma and Automation (automation - of course, that sounds just like an implicitness 🤣) have their own automation "mechanics".

Have you the possibility to deactivate both Apps (perhaps just one, then the other) for a short test with the affected user to do a cross check?

[Jack Brickey]

what or who is DEQ Jira? That sure seems like automation. Are you sure you checked legacy automation as well?

[Steve Dobrioglo]

Hi Jack. Thanks for the feedback!

"DEQ Jira" is Jira system. Yes, I checked legacy automation. We have several escalation rules there but all they do is add a comment to the issue and include various Jira users as for notification. Again, this happens to only one service desk tech. Initially, I thought maybe  this tech escalates without having an assignee but even with assignee set and then escalated to "Escalated to SDI" - it reverts back to "Escalated to SQL Admin".