SLA for Incident Priority upgrades and Downgrades

[Arun Sharma1]

We have requirement on SLA to be configured for Incident Priority upgrade and downgrade requirement.

1st case is downgrade: When priority is downgraded for e.g. P1 to P4, the SLA start time should be the incident created time. 

2nd case upgrade: When priority changes from "p4 to p3, p3 to p2, p2 to p1". The sla start time should be priority changed time (time when priority upgrade happened). it should cancel 1st case (i.e. downgrade).

not able to implement both the conditions with single SLA definition, 

[Dr Atul G- LNG]

Hi @Arun Sharma1 

Not possible in single SLA definition , as retroactive just check the value to be set. I am not sure try with dynamic SLA @Mark Manders any thoughts. 

[Mark Manders]

Your requirement is not how SLA's in ServiceNow work. Just create one for each priority (you could trigger the condition on 'changes from' and 'changes to'. I am wondering about the requirement though. How often do you change the priorities? And if something was created as a P4, there is a reason for that P4 (assuming it was assessed correctly). I haven't seen much companies setting their start time to when the priority was set. If a P3 is set to P2, it's mostly retroactive, but if the agreements state that this is the way, you will need to configure it like that.

Just make sure to also validate this one with your client: if a P4 becomes a P3, it is set to the priority change, but if a P2 becomes a P3, it is set to the creation of the incident? When you report on SLA to your clients, that will be hard to explain (and is very subject to SLA manipulation -> SLA almost breached, I just raise the priority from 4 to 3, then I have some extra time...)

Discuss this with your client/management, to be sure that this is the setup required.

[Pramod Pandey2]

Hi Arun,

I to have same requirement, can you please help me how you implemented this requirement.

Thanks

Pramod Pandey 

[Mark Manders]

You can't do this with one SLA definition. You will need a definition for each priority. And on a P1, it would be the retroactive start tot sys_updated_on.

Again: it doesn't really make sense from an ITIL perspective. An issue has a defined priority, based on impact and urgency, which can be in any way you define it to be, but a single user that can't log in on a non critical application which is defined as P3 and it turns out the application is down, which makes it a P2, still has the start time of the SLA set to when the incident was created.

It makes no sense to have a P2 with 8 hours and if you think 'hey.. I need 2 hours extra' you can just put it to P1 and get an extra 4 hours to solve it. It's absolutely bad practice!