Are SLAs supposted to stay when it no longer affects the ticket?

[Calvin]

Hi all, basically lets say a ticket is created in one type and it has certain SLAs connected to it. BUT it actually came through as the wrong type so a user changes it and thus the new SLAs are attached.

BUT the old SLA still display and looks like they're ticking down. As I understand it, they're not, it seems like its just sitting there. But it doesn't show up as paused or invalid it just looks like a normal SLA.

Is this supposed to be the case or have I developed it incorrectly?

Thanks!

[Walter Buggenhout · Accepted solution]

Hi @Calvin ,

SLA goals are based on JQL queries. When you set an SLA target, you also specify which issues the goal (and the associated timer) applies to.

From what you describe, there is an SLA goal set for both the original type that was created as well as for the new type that you moved the ticket into. And that results in the running timer, even after you updated the request (or issue type).

If you want to exclude certain issue types or request types, you should make your JQL filters attached to SLA goals more specific, so they only apply to the types you want.

Hope this helps!

[Calvin]

Hi Walter, thanks for this.

I guess my assumption was that it is keeping the old SLA in the view and just not running it once it no longer fits within the JQL filter.

But it sounds like it is more likely my second SLA and first SLA is both running? And if I change the SLA the old SLA should disappear off?

[Walter Buggenhout]

On the issue view you will see all SLA timers that apply for the issue based on the JQL filters of any SLA's you configured in your project. As long as the issue fits the JQL, the timer will be there. It is even possible that one issue will display several SLA timers because of that - intentional or not.

When an issue is updated and no longer matches an SLA's JQL criteria, that SLA should disappear (if it is still running). It may take a bit of time to recalculate.

[Calvin]

Thanks mate, seems like my JQL criteria I was using was incorrect, and due to an awry OR status it was still pulling in my new request type.

Had a second review at it and they do indeed delete (unless they were met in the past).