ServiceNow Service Level Agreements (SLAs) are contracts. In ServiceNow, the Service Level Agreements application allows you to create definitions to apply to the different kinds of task records in the system. The definitions are used to create records to track whether or not the terms of the contract were met.
The contract is defined in the SLA Definition (contract_sla table). The SLA Definition specifies:
- The amount of time allowed to complete the activity.
- A schedule and a time zone for the activity.
- When the definition applies (the Start condition).
- When the definition is done (the Stop condition).
- When the definition is suspended (the Pause condition).
The tracking records are created in the task_sla table. These records can be displayed in a related list on the associated task, to help people working on the task to see how much time has been used and how much time they have left to complete the work.
The record pictured had been created five minutes earlier, but you will notice the Actual elapsed time is still 0 Seconds. A frequent question is: why aren't the time values changing? The answer is because these are no timer widgets, like the Time Worked field on a task record. They must be calculated to make them change, and the code to do the calculations is in the SLACalculatorNG script include.
There are six scheduled jobs (sys_trigger records) that are the standard mechanism to run SLACalculatorNG and update the task_sla records. The jobs run with increasing frequency as you get closer to the expected breach.
There is a system property, glide.sla.calculate_on_display, which can be set to true. This will cause the 'Calc SLAs on Display' business rule on the task table to run whenever the task form is loaded. The business rule calls SLACalculatorNG for each associated task_sla record for that task and results in the related list showing the refreshed values. The glide.sla.calculate_on_display property is set to false by default.
Setting glide.sla.calculate_on_display improves the user experience by causing frequent updates to the records and the associated related list making the information appear closer to the expected timer behavior. As the Description in property states, because the calculations are done in the user's session thread as the form is loaded, the load will be slower. For many implementations, the delay will not be perceptible to users. However, if you have a large number of task_sla records associated to each task, and if you have heavily customized your implementation with business rules on the task_sla table, the delay could be substantial and you will want to leave this property set to false.
The scheduled jobs are always needed, because if a task is opened but is not being viewed or updated, the scheduled jobs will be the only source of updates to the task_sla records. Because of the improved user experience, the recommendation made to most customers is to set the property to true and try it out.
Some things to keep in mind when turning it on:
- In most cases, there will not be a perceptible delay.
- In some cases, there may be a slightly noticeable delay which is still acceptable in light of the improved user experience.
- If the delay on loading is unacceptably long, the property is set back to false and the scheduled jobs perform the updates.
For more information on SLAs, check out Iris Geist blog series Understanding my SLAs Part I — Scheduled jobs and the TASK SLA, Understanding my SLAs Part II - The Difference between Actual and Business elapsed times and Understanding my SLAs Part III — Pause Times.
2 Comments
