Preventing new Response SLAs from being attached, when incident priority changes

[CMH]

Hi Everyone, hoping I can get some ideas from the community...

So I have 4 SLA Definitions for Incident Response (one for each priority, P1, P2, P3, P4, with varying targets (1hour, 2 hours etc)).

The Start condition is basic. When a ticket of a certain priority is created, with a certain assignment group, the SLA is attached. The "state" of the incident is intentionally not included in the start condition, because in my world, the state of the incident does not change when a ticket is passed between assignment groups.

Now the issue I have, is when the priority changes AND the ticket REMAINS in the same assignment group.

Example:

Step 1: Ticket arrives in Assignment Group XYZ with Priority=1. The P1 Response SLA is attached.

Step 2: An agent performs the necessary action to trigger the "stop" condition on this P1 Response SLA - all good.

Step 3: During the subsequent handling of the ticket, the priority is changed to (for example) P2 (and the assignment group remains the same) - this then triggers the P2 Response SLA ...

The agents in the assignment group complain and say "well, I responded when the ticket first arrived in my queue, why are you asking me to respond again!?"

I assume this is quite a common scenario, so I wondered if anyone had found a way round it in the start\stop\pause\reset conditions.... without using any kind of scripting\customisation (I need to try and fix it with the "out of the box" settings)?

I have tried a few times to find a way, but I am not able. I know the SLA Definitions are all about "triggering" the SLA task under certain conditions, but what I am trying to do, is to prevent them from triggering in the first place.

Any suggestions are warmly welcomed, thanks in advance.

[Dr Atul G- LNG]

Hi @CMH 

Based on my understanding and experience, SLAs work based on conditions. When a condition matches, the SLA gets attached, which is exactly what's happening here. As humans, we may know that the 2nd-time response SLA shouldn’t be attached, but the system doesn’t know that because the condition isn’t explicitly defined. This is expected behavior.

To overcome this, you can add a state condition at the start to ensure the response SLA is not linked again.

[CMH]

Thanks for the answer AG! But specifically\sadly I am looking for a solution that does not look at the incident state (see 3rd paragraph of the question for the reason)

[AndersBGS]

Hi @CMH ,

i do understand why “state” is not in your condition, but at the same time this is also the solution to your problem.

 The reason stating this is, if you only start the response SLA when state is new, then it wouldn’t re trigger based on priority change. 

[Dr Atul G- LNG]

Hi @CMH 

I reviewed your question again, and unfortunately, there’s no other way around it. We need to understand that the system requires an identifier so it can check the backend and take action. As I mentioned earlier, the system isn’t human, so unless we provide additional parameters, the issue will persist. In this case, using the state as a parameter is the best approach.