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:
* 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 will be measured between the Start and Stop conditions below.
Time will be measured between the Start and Stop conditions below.
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.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.