Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

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

Steve G
Contributor
July 8, 2022

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.

Start
Begin counting time when
Entered Status: Waiting for Triage
Pause on (Optional)
Time is not counted during
 
Stop
Finish counting time when
Entered Status: Resolved
Entered Status: Waiting for Customer
Entered Status: Waiting for Support
--
b) TTR SLA
--

Time metric

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

Start
Begin counting time when
Entered Status: Waiting for Support
Entered Status: Waiting for Triage
Pause on (Optional)
Time is not counted during
Status: Waiting for Customer
Stop
Finish counting time when
Entered 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.2
4. Workflows
* We only have one workflow:

Workflow - JIRA Service Desk IT Support Workflow generated for Project ITHELPDESK

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

1 answer

0 votes
Tom Lister
Community Champion
July 8, 2022

Your config shows SLA starts when moved into other states.
So depending on where you move to from resolved then you will restart the SLA.

Which automation tool are you using? Automation for Jira or native service desk automation.

In our service desk we have a transition on Done that loop back to Done to enable us to change Resolution values if required.

Steve G
Contributor
July 8, 2022

Hi @Tom Lister 

Thanks for your obviously constructive reply.

1) Please pardon my innocence, can you clarify this for me please?

"Your config shows SLA starts when moved into other states.
So depending on where you move to from resolved then you will restart the SLA."

2) We are running native service desk automation

Thanks for any further input you and anyone else can offer.

Regards,

Steve

Tom Lister
Community Champion
July 8, 2022

Hi @Steve G 

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.

Steve G
Contributor
July 9, 2022

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

Example Jira TTR.png

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
Community Champion
July 9, 2022

Hi @Steve G 

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

Suggest an answer

Log in or Sign up to answer