Service Level Management (part 1/2)

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.

Service Level Agreements (SLA) Plugin

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:

• Table – which table is this SLA defined on
• Start condition - when the timer is running (active condition)
• Stop condition - when the timer stops counting (finishes)
• Pause condition - when the timer is paused (suspended)
• Duration – the actual amount of time for service level, counted in business hours
• Schedule and time zone – definition of business hours used for calculation

SLA Definition

To create a new SLA navigate to Service Level Management > SLA > SLA Definitions.

• Click the button New and fill the name of your SLA on the form;
• Select the desired table
• Select the type of SLA (SLA, OLA, UC); the type has only informative meaning, has no effect on the calculation.
• It is also possible to select a workflow which defines escalations or notifications. The default workflow ‘Default SLA workflow’ sends notification to the ticket assignee when 50%, 75% and 100% of SLA time is reached. At 100% of SLA time (when the SLA is breached) a notification is also sent to the assignee’s manager. If this workflow does not suit your company’s policy, a new workflow can be created or a different one used.

Additional fields that need to be filled are related to the time definition of an SLA. At first it is necessary to define how the duration will be provided. Field ‘Duration Type’ specifies if the duration is an amount of time (value ‘User specified duration’) or relative value such as ‘End of Next Business Day’. These relative values are stored in the table Relative Durations (System Scheduler > Schedules > Relative Durations) and are defined by a JavaScript code. New relative durations can be created by system administrators. If the duration type is ‘User specified duration’ then the field ‘Duration’ is visible on the form and it is possible to enter an appropriate value. This duration must correspond to the selected schedule – business calendar (in the field ‘Schedule’). It is also possible to specify a time zone which is used with the calculations.

Example:

If the schedule is defined as 5x8 (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 5x8 = 40 hours. If you enter 5 days to the ‘Duration’ field it is 5x24 = 120 hours that equals to 15 working days for 5x8 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.

Example:

Table: Incident

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.

Task SLA Record

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 (24x7) 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:

• SLA update (already breached): repeats every day
• SLA update (breach after 30 days): repeats every 5 days
• SLA update (breach within 1 day): repeats every hour
• SLA update (breach within 1 hour): repeats every 10 minutes
• SLA update (breach within 10 min): repeats every 1 minute
• SLA update (breach within 30 days): repeats every day

Important System properties for SLA

• snc.sla.default_conditionclass
  • defines which condition class will be used as default
  • value: SLAConditionBase
• snc.sla.engine.async
  • defines if the business rule “Run SLAs” runs asynchronously
  • value: false
• snc.sla.engine.version
  • defines which version of the SLA engine is used (2011, 2010)
  • value: 2011
• snc.sla.schedule.source
  • defines how schedule is determined for the Task SLA record
  • value: sla.schedule
• snc.sla.timezone.source
  • defines how timezone is determined for the Task SLA record
  • value: task.caller_id.time_zone
• sla.calculate_on_display
  • defines if Task SLA records should be recalculated when the ticket is opened
  • value: true

In the next article we will describe the different ways how SLAs can be defined in ServiceNow.