ServiceNow SLA Upgrade/Downgrade Scenario

All you should know about how to achieve the SLA upgrade/downgrade scenario when priority changes. 

ServiceNow SLM provides the capability of tracking and documenting all service commitments between IT, service providers, and customers. What if, there is a business scenario where SLA should upgrade or downgrade when the priority of incident/case changes. This article will enable you to understand all about how we can achieve this business scenario without any customization.

 

• Business Requirement 1 (Upgrade):

Whenever priority changes from P4 to P3 or P3 to P2 or P2 to P1, then-new SLA should get attached as per current priority, and the SLA time should be priority changed time.

 

• Business Requirement 2 (Downgrade):

Whenever priority changes from P1 to P2, P2 to P3, P3 to P4, then New SLA should get attached as per current priority, and the SLA time should be created time of the record (incident/case).

 

• Challenge:

We cannot achieve this business requirement through one SLA for each priority, as one SLA can either be retroactive or not. Both at the same time is not possible and, we don’t have Changes, Changes to, and Changes from in SLA condition builder.

 

• Solution:

Create 2 SLA for each priority, one with a retroactive start as ‘true’, and the other with retroactive start ‘false.’ Specify the different names for both SLA.

For example, P2 upgrade SLA is named as P2_Resolution_Upgrade, and P2 downgrade is named as P2_Resolution_Downgrade and creates one SLA called ‘Cancelled SLA’.

Now, as we have 2 SLA’s created for a priority OOB SLA Engine will create both task SLA whenever condition met for SLA.

The next step is to detach the incorrect task SLA when priority upgrade/downgrade.

To achieve this, create two business rules one would be running when priority is downgraded, and the second would be running when priority is upgraded or when any other changes are done on incident/case.

• If priority is downgraded, then find the task SLA where “SLA name contains current priority AND name contains Upgrade and Stage is In Progress” and set state = Cancelled and SLA definition = Cancelled SLA, Active = false, task = ‘ ’ inside the business rule.
• If priority is upgraded, then find the task SLA where “SLA name contains current priority AND name contains Downgrade and Stage is In Progress” and set state = Cancelled and SLA definition = Cancelled SLA, Active = false, task = ‘ ’ inside the business rule.
• If some other attribute changes on the incident, then find the latest SLA which got attached, as per the-

• •  “SLA name contains current priority and orderByDesc with the created time of task SLA.”
  • and set state = Cancelled and SLA definition = Cancelled SLA, Active = false, task = ‘ ’ inside the business rule script.

 

To avoid any impact on SLA reporting, create a table clean-up record on task_sla table with ‘sys_updated_on’ and age in seconds to 30 mins or one hour, and condition should be SLA Definition is ‘Cancelled SLA’.

This clean-up record will remove all the unwanted Cancelled SLA’s from the system. We achieved the upgrade/downgrade scenario without creating any new field on incident or case.

 

PFB screenshot which shows Task SLA’s in case of priority upgrade P4 – P3 – P2 (current)

PFB screenshot which shows Task SLA’s in case of priority downgrade P2- P3- P4 (current)

 

Written By:

Palash Mahajan
Technical Consultant