Happy to share my solution which could possibly be adapted to other scenarios. Isn't beautiful but achieves the desired outcomes and typically involves workflow changes.]https://community.atlassian.com/t5/Jira-Service-Management/Resetting-the-SLA-clock-in-Jira-Service-Management-Service-Desk/m-p/2078605#M3035

I'm with Susan.  This issue is NOT resolved.  Restarting / setting the counter to back to zero, for the the SLA through Automation is most definitely needed.

@Charlie, I'm not sure why this is closed?  I don't see how a manual recalculation on a single issue solves the problem?   The reason we require this functionality is the following:

In our organization our SLA with our customer is to provide updates on critical issues every 2 hours.  So we need the "time to update" SLA to reset every time we comment to the client.  This needs to continue until the issue is resolved.

What we need is the ability to automate a restart of the SLA when an event happens (in this case comment to the customer).  It's not a recalculation, it's a restart. 

In exceptional cases (typically happens when the portal setup is not correct), some SLAs get started & stopped resulting in an incorrect SLA after the portal setup (e.g. linked calendar & working hours) is corrected. 

example: the SLA 'Time To First Response' stopped with a wrong value, due to portal being linked to an incorrect calendar, taking Australian holidays into account instead of the correct Japanese holidays.

In previous JSD versions, we had a workflow transition in place to remove the faulty SLA timer on the issue (post function that clears the SLA custom field value) & inform the reporter user via a comment. 
However, just recently discovered that since the JSD 3.11 , clearing a SLA custom field (setting the field value to empty) no longer seems to be possible (no errors logged, no custom fields cleared either)

Seems that a "Restart SLA" would not be the right fit for purpose here; but if we could get a stopped SLA re-calculated we could correct the value after the portal setup correction in this way, rather than emptying it. 

cc: @katarzyna.pawlak2 any plans to add this to your plugin?

This is really needed the feature, we are using Jira ServiceDesk Server

Even on Cloud?

Hello,

You can achieve it using post function Restart SLA which is available in our app Extension for Jira Service Desk.

Ran into this issue when trying to set up an SLA that monitors whenever a support ticket is waiting for a customer response (and closes the ticket if breached).  This is surely a fundamental requirement of a Support Desk? 

+1 - Just ran headlong into this issue

Please implement

I would like that too.

We would like to use SLA for ticket updates. We need to reset and start the SLA when public comment is made.

+1 for this functionality. We use it an SLA to auto close after an issue has remained in resolved for a period of 5 days. If the issue is reopened after 2 days and then re-closed, the timer continues and so closes after 3 days which is inconsistent.

+1 for resetting the SLA after a comment to customer is added (ie an SLA that addresses the frequency of support communication to customer until resolution)

This would be amazing for not only for manual updating but the ability to reset an SLA when a ticket moves between projects. Because different teams are escalation points it greatly hurts their metrics when a ticket is not immediately moved to their desk. This is absolutely vital as our Service Desks and general usage of Jira grows.

Huge issue around SLAs here, definitely something we need to see addressed.

I use an SLA to track the time waiting to hear from a customer. When the SLA timer is breached, the issue is auto-closed. This is very helpful, however, if the issue goes back and forth between the customer and myself several times it is possible for the SLA to be breached and the issue to be closed prematurely. Confusion and sometimes anger are the results of this .

Please provide a way to enable SLA timer reset when an issue transitions to a specific state.

+1 for resetting the SLA after a comment is added

+1 Not only reset but being able to manipulate the SLA custom field value.

+1 This feature is needed for a JSD admin to roll out a Service Desk from a clean slate once configuration and testing is done.

We use an SLA to time issues out from lack of response. Without this feature, we can only ever time an issue out once unless we create multiple SLAs for the same thing! I can (almost) not believe this hasn't been implemented.

+1

very important

Optional a restart SLA option would work aswell for now. Because if the Issue is Done but the customer re-opens the task the SLA is already done and can not be used anymore. That forces us to manually check the times of every action made after re-opening because we have SLA's with our customer and have to react in time and prove it in a monthly report. 

I would like to set up an SLA that resets the clock once action is performed

Our users need to be updated every 4/8 hrs based on priority of the incident.

I need rule for example that once first response has been action an SLA for 8hrs starts to count down. but if I send update to customer I need the SLA to reset and begin 8hr count down again.

Can we update SLA for the closed JIRA issue for reporting purpose? We would like to update closed date and the SLAs of resolved or closed JIRA issues.

SLA going to green means the SLA timer was stopped.  This can be done in the SLA settings.  Set the condition that you need for it to stop running.

Is there anyway to modify/update SLA once we update the closed date of a JIRA issue. There are times when an agent finishes his work on an issue in time, but forgets to close the issue. We would like to have the ability to modify the SLA (from red to green) of a JIRA issue ( any status) for reporting purpose.

Actually.... there is an issue:  The SLA is green with a check when the reset is done, but it's not removed from the issue page.

Can there be a 'remove SLA' option?

Never mind!  I had to add an additional condition to stop timer in my sla.

Awesome, the reset SLA will clear the sla if the status is stopped.

In regards to Service Pack.  I've downloaded it and set up a reset SLA on a transition.  What if I want to completely clear the SLA... it doesn't seem to be doing this.

Example:

I have an SLA 'Time to autoclose - customer acceptance'.  If we're done working on an issue, we want to wait for some feedback for say 48h.  And then if there's no feedback, close the issue.

Say a tech noticed that the issue is actually not fully resolved and then switches the status back to 'work in progress'.  I want to completely clear the SLA, otherwise it's going to autoclose.

We often have issues moving from project to project. In fact, the majority of issues in our project originate from other projects.

One of the SLAs which is not providing accurate data for us is a "Time to assign" SLA. If an issue is created, assigned, worked on, etc. in another project, but then moved to our project after some period of time, we are often already many hours over the SLA since the start condition is on Issue Created. It would seem that the Issue Created event and start condition should only start once the issue is moved to our project, not when the issue was created elsewhere.

Our organization has a need for the SLA clock resetting as part of a workflow, in our case whenever a comment has been added to a ticket. It would be great to see this feature extended to the point where its part of the configuration for an SLA metric. In my mind, there would be a 4th column in the metric configuration, next to Start/Pause/Stop, called something like "Reset After," which would allow the clock to automatically reset when one of the prebuilt conditions is met.

This way we'd be able to have a flow specific to comments that alerted us to lapses in communication, as well as being able to report on the time the customer has spent waiting on a response from us.

Thanks!

Adding on here: my organization has occasional situations where tickets that are resolved must be re-opened. Some SLAs (such as our 'Time in Progress') restart at 0 and begin counting again (instead of adding the time which I would want). Our time to resolution SLA does not restart, and remains set at its original value, even though there is more work and time needed to resolve the ticket. It would be great if the the time to resolve value kept going once start conditions of the SLA re-occur.

Would it be possible to add a 'restart' or 'continue counting' option when creating SLAs where you can set it to count an SLA based off certain conditions, and if certain conditions are met, to keep counting. Specifically we want the time to resolve SLA to continue counting when a ticket is re-opened instead of stopping when the first stop condition is met.

Any suggestions as a workaround would be great, as currently our SLA metrics are not meaningful due to these limitations.

Thank you!

When issue is moved from one issue type to another there is no way to reset the SLA.

Also could you please help me in below scenario if it is possible?

Suppose we have issue type Incident and SLA is configured via service desk to 8 hours. Issue is created using issue type as Incident. Now later we figure it out that it is not a Incident and it is a Bug or Service Request and we moved it to other issue type.

There is no SLA for Bug or Service Request.

So ideally it should clear the SLA field and should not show on view issue screen. But it is still showing the SLA as resolved/done.

How can we clear/reset/make it invisible?

Thanks.