Re-opening a Jira ticket resets the SLA clocks back to full SLA available

Question

Dear all,

1. Issue description

* I am experiencing re-opening a Jira ticket resets the SLA clocks back to full SLA available

* This happens if e.g. I amend the Resolution on a ticket (I am aware there is a request for the Atlassian to make the Resolution field editable, but since that request is over 15 years old, I don't have much hope that feature will be made available soon:

[JRASERVER-11444] Add ability to edit resolution - Create and track feature requests for Atlassian products. )

* Hence on my current issue, the SLA clock being reset to full SLA available is also having the effect of resetting (when applicable_, failed ticket SLA being reset to no longer being failed

2. SLA configurations:

a) TFR SLA

--

Time metric

Time will be measured between the Start and Stop conditions below.

StartBegin counting time whenEntered Status: Waiting for TriagePause on (Optional)Time is not counted during StopFinish counting time whenEntered Status: ResolvedEntered Status: Waiting for CustomerEntered Status: Waiting for Support--b) TTR SLA--Time metric

Time will be measured between the Start and Stop conditions below.

StartBegin counting time whenEntered Status: Waiting for SupportEntered Status: Waiting for TriagePause on (Optional)Time is not counted duringStatus: Waiting for CustomerStopFinish counting time whenEntered Status: Resolved--* It is interesting that this issue occurs for the both the TFR & TTR SLA* Both the TFR and TTR SLA have only the following status common to both they 2 SLAs to start the SLA clock:Entered Status: Waiting for Triage* I struggle to opine that having 'Waiting for Triage' as a status to start the SLA is a mis-configuration (I am open to correction of corrections of course)3. Jira version* We run Jira Data Centre v8.22.24. Workflows* We only have one workflow:Workflow - JIRA Service Desk IT Support Workflow generated for Project ITHELPDESK

Can anyone please offer guidance on how I may resolve this issue?Any help is appreciated.Regards,Steve

Tom Lister_fo1j4e · Answer

Hi @S

Tiem to resolution SLA's usually start when the issue is created to measure start to finish completely.

When an issue is 'resolved' by the last step in a workflow the resolution value is set to indicate a reason. (Although resolution values should be kept simple on not too many IMHO)

In the workflow, if there are paths back into the workflow from the end state, those transitions should have a step to 'Inset the resolution' to show the ticket is back in play.

Following that protocol you can safely use  'resolution = Unresolved' to find open tickets where needed.

Resolution set and resolution cleared are events in Jira that can be listened for i.e. the SLA can restart when the resolution is cleared if required.

I think the SLA restarts from 0 but I haven't need to know that for a while so it will need testing or RTFM.

This is a standard service desk SLA

S_r3fexp · Answer

Hi @Tom Lister

* Before searching for the page you suggested, I found this:

https://confluence.atlassian.com/servicemanagementserver/setting-up-slas-939926373.html

* That page links to the page that you seem to suggest re multicycle in your reply above

* The page that I've added the weblink for has a fascinating example TTR SLA config, with completely different logic to what I currently have configured

1) the start conditions are:

Issue created

Resolution cleared

2) The pause condition is:

Status closed

* I humbly struggle to get my head around why status closed would be selected as a pause condition

* Could it be a mouse click error by the person who put that graphic together, meaning 'status closed' was selected in error instead of 'waiting for customer' (2 positions higher that 'status closed' in the menu in the graphic)? Likely not, Atlassian are the Jira experts, I defo am not

3) Rather than a stop condition of, 'Entered status: Resolved', the selected stop condition is 'resolution: set'. That is very interesting in the context that 'resolution cleared' is listed as a start condition

That webpage though doesn't clarify if the 'resolution cleared' start condition being triggered starts the SLA clock:

a) from zero. Or;

b) from the position at which the SLA clock was stopped

I welcome you and anyone's thoughts on this please? I've also used the feedback on that webpage to request if they could clarify that webpage in the context of the observations that I've mentioned in this post. As mentioned, since Atlassian are the experts I suspect that the webpage will be presented exactly as intended and it is I who has misinterpreted something. There seems though no harm politely asking them.

Rgds,

Steve

Tom Lister_fo1j4e · Answer

Hi @S

glad to be obviously constructive. Although the reference to automation was a glitch in the matrix.

My reading is this, for example TFR SLA, starts on Waiting for Triage.And stops on Resolved. If once resolved, the ticket is moved back to Waiting for Triage, the SLA will be restarted.

I’m not sure of the top of my head if there is setting to stop SLA’s restarting. Google multicycle SLA’s for details of the feature.

you could also try adding ‘Resolution is unset ’ to the start condition to stop this happening.