Service Level Agreements

From ServiceNow Wiki
Home > Deliver > Planning and Policy > Service Level Management > Service Level Agreements
Jump to: navigation, search
Note: This article applies to Fuji and earlier releases. For more current information, see Service Level Management Concepts at

The ServiceNow Wiki is no longer being updated. Visit for the latest product documentation.

1 Overview

A Service Level Agreement, or SLA, is a record which defines a set amount of time for a task to reach a certain condition. If the task does not reach the condition by a set amount of time, it is marked Breached.

SLAs are used to ensure that a task reaches end conditions within a certain amount of time, such as ensuring that an incident is closed or resolved within a few business days. The success rate can be reported on, and actions can be triggered at different times during the SLA's life-cycle (for example, notifying the manager when the SLA reaches 75% of its allotted time.)

1.1 OLAs and Underpinning Contracts

The Task SLA engine provided by the plugin can also be used to define OLAs or Underpinning Contracts in exactly the same way as SLAs. The only difference between SLAs, OLAs, and Underpinning Contracts is the Type field on the Task SLA form. Changing the type field does not change the behavior of the Task SLA.

For an example of an OLA, see Defining an OLA for Catalog Fulfillment.

2 SLA Components

There are four major components that work together to power the Service Level Agreements Plugin:

  • SLA Definition: the record which defines the conditions that trigger the SLA.
  • Task SLA: the individual instances of the SLAs associated with particular tasks.
  • SLA Workflow: the workflow which powers events or actions based on the SLA definition.
  • SLA Automation: the business rule and scheduled job that automate the SLA.
  • SLA Conditions and Script Include: a script include and reference record that can be used to customize the transitions between different SLA states.

For more information about task SLAs, see Understanding my SLAs Part I - Scheduled jobs and the Task SLA on the ServiceNow Community.

2.1 SLA Definition

The SLA [contract_sla] table contains the definitions of SLAs, which determine when and how they track time on tasks.

SLAs are defined by three sets of conditions:

  • Start Conditions
  • Pause Conditions
  • Stop Conditions

When the start conditions are met, the SLA begins timing towards the defined duration. When the pause conditions are met, the SLA pauses its timing. When the Stop conditions are met, the SLA stops timing and determines whether the SLA was Achieved or Breached.

To see the conditions in action, see Demo Walkthrough. For more information on defining SLAs, see Defining an SLA.

For more information about pause times, see Understanding my SLAs Part III – Pause Times on the ServiceNow Community.

2.2 Task SLA

The Task SLA [task_sla] table stores each of the individual SLAs attached to particular tasks. These are accessible in a related list on the Task's form.


2.2.1 SLA Stages

The following stage values are defined for Task SLA records:

  • In progress
  • Achieved
  • Breached
  • Cancelled
  • Paused
  • Completed

2.2.2 Time-Based Fields

The six time-based fields on the Task SLA contain the crucial information powered by the Task SLA:

  • Actual Elapsed Time: time between start time and now (minus pause duration).
  • Actual Elapsed Percentage: percentage of total SLA that has elapsed (minus pause duration).
  • Actual Time Left: time remaining until SLA breach.
  • Business Elapsed Time: time within the specified schedule between start time and now (minus pause duration).
  • Business Elapsed Percentage: percentage of total SLA that has elapsed within the specified schedule (minus pause duration).
  • Business Time Left: time within the schedule remaining until SLA breach.

These fields are dynamically populated by a scheduled job.

For more information about elapsed times, see Understanding my SLAs Part II - The Difference between Actual and Business elapsed times on the ServiceNow Community.

2.3 SLA Workflow

The SLA Workflow is a workflow defined in the Workflow Editor, which powers behavior in response to the SLA. This allows email notifications, script actions, and any other workflow activities to be triggered at various stages in the SLA.

For more information, see Creating an SLA Workflow.

2.4 SLA Automation

SLAs are calculated and assessed by a business rule and a scheduled job which run in the background.

Note that the mechanisms that control SLA Workflow and SLA Automation are completely independent of each other. Many customers have a requirement to send out email notification from the SLA Worklfow showing the current elapsed percentage of the SLA. However, this does not work because using percentage in a notification only displays the most recently calculated value of the task_sla. The results are inaccurate values sent out in email when using SLA calculated values in a task_sla email notification.

One solution is to specify elapsed percentage in SLA notifications by using notifications for each percentage level. For example, an email notification for "75 percent SLA Warning" is created and a special event is used to trigger that notification. The event can be called "sla.warning.75". Another solution would be to hard-code these email notifications to fire off at a specified duration percentage, and configure the workflow linked to that SLA definition to send an email notification after waiting an elapsed percentage.

2.4.1 Business Rule

In the 2010 engine, the asynchronous business rule Process SLAs runs after every task is inserted or modified and evaluates the Start, Pause, and Stop conditions for the SLA.

In the 2011 engine, the Process SLAs business rule has been replaced by the Run SLAs business rule. The Run SLAs business rule is not asynchronous. To make the 2011 SLA engine asynchronous, navigate to Service Level Management > Administration > SLA Properties and set the Run the 2011 SLA engine asynchronously after task insert or update operations (com.snc.sla.engine.async) property to Yes.

For more information about the 2010 and 2011 engines, see Moving from the 2010 Engine to the 2011 Engine.

2.4.2 Scheduled Jobs

ServiceNow recalculates SLAs based on when they are breached, using these scheduled jobs on the Schedule Item [sys_trigger] table.

  • 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
Note: After 365 days, ServiceNow does not recalculate breached SLAs.

2.5 SLA Conditions

The SLA Condition record references a Script Include to provide scriptable condition rules for the transitions between different SLA states. By defining methods as part of an SLAConditionBase sub-class, it is possible to script under what conditions an SLA is marked Paused, Completed, Cancelled, and when the SLA is Attached or Reattached.

For more information, see Modifying SLA Condition Rules.

3 Menus and Modules

  • Getting Started - Links to this document on the wiki.
  • SLA
    • SLA Definitions - The SLA [contract_sla] list.
    • SLA Homepage - A Service Level Management homepage
  • Administration
    • SLA Properties - The properties page for Service Levels.
    • SLA Condition Rules - The list of Condition Rules for SLAs.
    • Workflow Editor - The graphical interface for creating and editing workflows.

4 Demo Walkthrough

The following walkthrough uses the demo SLAs available with the plugin to illustrate an SLA being achieved, breached, and paused on the Incident [incident] table.

  1. Navigate to Incident > Create New.
  2. Set the Priority to 1 - Urgent.
  3. Save and then Reload Form.
  4. The Related List Task SLA should now have two SLA's:
  5. Change the priority to 2 - High.
  6. Save and then Reload Form.
    The two Priority 1 SLAs are now marked Cancelled and a Priority 2 SLA has been attached, because of the conditions on the SLAs:
  7. Change the Incident State to Awaiting User Info.
  8. Save and then Reload Form.
    Awaiting User Info is a Pause condition on the Priority 2 SLA, so the SLA will be marked Paused:
  9. Change the Incident State to Active.
  10. Save and then Reload Form.
    Because the Incident is no longer in a pause condition, it will resume timing:
  11. Change the Incident State to Resolved.
  12. Save and then Reload Form.
    The SLA will now be marked either Achieved or Breached, depending on how much time has elapsed:

5 Installing the Service Level Agreements (SLA) Plugin

5.1 Activating the Plugin

The Service Level Agreements (SLA) Plugin is installed by default for all new instances. Older instances will need to activate the plugin.

5.2 Getting Started

For information on implementing the plugin on instances that have been using the base system SLA engine, see Getting Started with the SLA Plugin.

Was this article helpful?
Yes, I found what I needed
No, I need more assistance