Service level management is supported in ServiceNow via the Service Level Agreements (SLA) Plugin and its extensions. This plugin also allows us to define OLAs (Operational Level Agreements) and UCs (Underpinning Contracts). We will explain how SLAs can be created and how the calculation of SLAs works in ServiceNow in two articles. We will also describe different ways of defining SLAs and explain in which situations they are the most suitable solution.
There are at least three ways to define service levels in ServiceNow. The main difference between these approaches is that they fit for a different number of service levels used and how these are organized into logical groups (by contract, by service). Generally it is possible to use different approach per process (table) in ServiceNow.
In this part we will describe basic properties of an SLA in ServiceNow and how calculation of SLAs works. The SLA plugin is installed by default for all new instances. With this plugin, service levels can be defined for the task table and all its child tables. These tables can contain incidents, change tasks, catalog tasks but also tasks from another applications (processes) like Facilities Service Management, SDLC Scrum Process and Human Resources Service Management. Service levels can be defined for all of those. The plugin enables the definition of timers with the following parameters:
To create a new SLA navigate to Service Level Management > SLA > SLA Definitions.
If the schedule is defined as 5×8 (8:00 – 16:00, Mo-Fr) and the SLA duration is defined as 5 working days then the real duration is 40 hours (or 1 day, 16 hours) because one working day is 8 hours, so 5 days are 5×8 = 40 hours. If you enter 5 days to the ‘Duration’ field it is 5×24 = 120 hours that equals to 15 working days for 5×8 schedule.
For the calculation of the SLA’s target date it is also important to specify whether the SLA should be counted from the time when the start condition became valid or if a so-called “retroactive start” should be used. This means that it is possible to specify a field from the target table (only date fields) which contains the start date. It is handy for example in the case where SLAs should always be counted from the incident creation date, but during incident classification phase the operator changes the priority of the incident and therefore another service level is used for the SLA calculation.
The most important part of defining an SLA is to correctly set up its conditions (start, pause and stop). The start condition is a tricky one. This condition must be evaluated as true for the SLA to be used. Generally this condition should be used to identify tickets to which this SLA should be applied and must be valid (true) for the whole lifecycle of the ticket when SLA should be measured (to the point when the stop condition is valid). We can call it “Run condition” since whenever it is true, the SLA counts. The stop condition simply identifies the moment when the SLA is fulfilled and the pause condition is used to suspend the SLA timer. See the diagram below for a detailed state-transition explanations. SLA timer records (Task SLA records) are created when the start condition is valid and the stop condition is not. If the start condition is evaluated as false during the ticket lifecycle (and no other conditions apply), the SLA timer is cancelled.
This behavior applies when the SLAConditionBase class is used for stage transitions. The condition class used is defined in the SLA definition and can be changed to an existing or a new condition class.
Start Condition: Priority = 3 AND Active = true
Pause Condition: Incident state = Awaiting User Info
Stop Condition: Incident state = Resolved OR Incident state = Closed
The start condition indicates that this SLA will be used for all incidents with a priority of 3 (Active = true just prevents the accidental start of this SLA for inactive tickets). SLA timer is stopped when the incident is resolved. Furthermore, when more information is required from the user the timer is suspended. If somebody changes the ticket priority sooner than the incident state is Resolved or Closed, the SLA is cancelled.
When a ticket is created and it meets the start condition of an SLA definition (defined for the given table with the SLA plugin active) then a Task SLA record is created (in the table “Task SLA”). This record is an instance of the SLA timer and contains all the data concerning the SLA definition related to given ticket. The schedule and time zone currently used for the calculation are also visible. Additional fields contain date and time of the start and the currently planned end date (when the SLA will become breached). Should the SLA be fulfilled, date and time when it happened will also be visible. The most important part of a Task SLA record are the details about actual elapsed time and business elapsed time. Users can easily find information on how much time was consumed and how much still remains until the SLA is breached. Actual time is calculated based on calendar days (24×7) and business time is based on business calendar (which is defined by schedule). Task SLA also has a stage field which indicates whether the SLA is still active (In progress) or it was completed, cancelled or paused.
A ticket can have several Task SLA records (if Start Condition of SLA definition was at least once met). They can be paused, closed or cancelled individually based on the SLA conditions.
Task SLA records are recalculated every time the ticket is opened in web browser. It is done by the business rule “Calc SLAs on Display” if system property “glide.sla.calculate_on_display” is true. Furthermore when the ticket is modified the following actions can happen: new Task SLA record can be created or an existing Task SLA record can change its state or get recalculated. These operations are executed by the business rule “Run SLAs”, which runs synchronously by default. The business rule “Process SLAs” is used only when the ServiceNow instance is using the old 2010 engine (old engine description is not a part of this article).
The Task SLA records are also being recalculated periodically by scheduled jobs. The frequency of this recalculation is based on the proximity of Planned End Date. Predefined scheduled jobs:
In the next article we will describe the different ways how SLAs can be defined in ServiceNow.