The SLAs are not taking the times according to the priority

[Nathalia Barbosa]

I have configured the times for each priority, but it always takes the time of "All remaining priorities". What am I doing wrong?

[Rik de Valk]

Hi @Nathalia Barbosa , 

I highly recommend not to use Status Category as a criteria for the SLA goal. 

Your 'Time to Resolution' for example, will start counting on issue creation. And it will finish counting when the status is Finalizada. 

However, your goal only applies to issues with statusCategory To Do and In Progress. And as soon as the status is in statusCategory Done, the 'All remaining issues' will apply. 

So even if this SLA would work, it wouldn't give you any useful resutls. 

So instead, use a JQL such as:

Type in (Incident, 'Service Request')

To determine the scope for the Goal. This way, all Incidents and Service Requests will follow your SLA goals per Priority. 

Kind regards, Rik 

[Rick Westbrock]

My first thought is that you have the To Do status category in two different SLAs, might JSM be getting "confused" and unable to decide which SLA to apply?

Even if that is not what is happening I would think that by having two possible SLAs apply to the same issue that you would end up with unpredictable results. My design is normally to make SLAs mutually exclusive so that even if the system arbitrarily decides which one to apply it's still predictable which SLA will be applied to any given issue.

[Josh Costella]

Hi @Nathalia Barbosa 

I was able to get the SLA to behave as it should. But I agree with @Rod , try to utilize a more consistent data point like Request Type. 

[Rodney D'Souza]

I would say that this is normal behavior for how you have configured the SLAs.   Specifically, JSM (nor I) does not think it makes sense to have SLAs configured by dynamic fields like "Status Category". 

For a test to convince yourself of where the problem lies, please remove Status Category from the condition (you can put something like issue type instead if you'd like) and then you should see that it picks up the rest of your SLA configuration.

[Rick Westbrock]

Doesn't every status value have to have a status category? I'm not sure I understand why Status Category is a "dynamic" field, do you mean something more like calculated field?

[Rodney D'Souza]

Rick, the status category is defined when you create a new Status value as a global admin OR the out-of-the-box Status values defined by Atlassian already have them defined.  

By "dynamic" I meant in this case she is changing what the SLA will be as the issues go through the workflow, which is not how SLAs should be defined.  SLA queries should be defined by Issue Type or Request Type or something "static" like that from the issue perspective.   Atlassian provides the ability to also define further by Priority, which is a very common use case.       Beyond that Atlassian allows you to then define when to start, pause and restart the SLA timers by STATUS - and this how how Status should be used in SLAs, not in the initial query.

[Rick Westbrock]

Thanks for explaining that "dynamic" referred to the Status of an issue changing over its lifecycle as I didn't quite pick up on that. Totally agree that basing an SLA on a field that will definitely change value over time isn't the best design. Even though the request type or priority can change that is much less likely than the 100% chance of the Status changing.