Varying SLA End Times as Incident Priority is Changed

[Andrew126]

Hi,

I have a requirement I am trying to meet regarding SLA duration as Incident priorities change. It is as follows:

When an incident priority changes to a lower level, the SLA resolution time will be the time for the lower priority with a retroactive start.

Whan an incident priority is increased, the remaining SLA time will be the lesser of the remaining resolution time at the lower level, or the full SLA time for the higher level, starting at the time the priority is changed.

I'm not sure how/if this can be achieved. I've looked at altering the end time of an SLA using scripts, but couldn't see how to make that work. I've looked at applying scripted filters to the SLA start conditions, but that won't work with the architecture of SLAs. I think I might need to create the Task SLAs using a script, but am sure there are a lot of pitfalls to that too.

Does anyone have any idea of how to achieve this?

Thank you all in advance.

[Community Alums · Accepted solution]

In the case that you describe, If a ticket changes to a higher priority I would leave both SLAs attached and running and only stop them on resolution / closure.

To do this for say a p1, cancel conditions would be priority changes to p2 or p3 or p4.

To do this for say a p2, cancel conditions would be priority changes to p3 or p4.

To do this for say a p3, cancel conditions would be priority changes to p4.

To do this for say p4, there would be no cancel conditions.

This way, if the ticket changes to a lower priority, you remove the higher priority SLA, but if it changes to a higher priority, it is not removed.

Example:

P4 timer starts (say 8 hours), after 7 hours 30min, you change it to a P1 (say 1 hour).

You don't stop the P4, so after 30min the P4 breaches but the P1 is still attached in a non breached state.

Then say you closed it 15min later (total run time 8h15min) you have a breached P4 and a passed P1 (with 15min remaining that is now stopped.)

To make the start times work correctly, you may have to make 2 SLAs for each priority, one for attaching to a record where an SLA exists that does not use retroactive start time, and a second one that attaches when no SLA exists that does use retroactive start time.

[kchorny]

This question has an accepted solution, but how was it accomplished?  

This piece has me scratching my head:

"To make the start times work correctly, you may have to make 2 SLAs for each priority, one for attaching to a record where an SLA exists that does not use retroactive start time, and a second one that attaches when no SLA exists that does use retroactive start time."

How do you configure an SLA to start when another one does or doesn't exist? Do you create a custom field and mark it when a retroactive SLA has been applied? Seems like that should be unnecessary, but at this point I'm not seeing another option. 

This would be so much easier if I had Priority options of 'changes to' and 'changes from'....

[Developer3]

I am facing similar requirement (when priority is upgraded on incident (for ex: P3 is changed to P2 or P1), a new sla needs to be triggered and when priority is downgraded (for ex: P3 is changed to P4 or P5), the SLA has to extend with the original start time) but not finding the efficient way to establish this. Please let me know if u have a solution for this.