Loading

Service Level Agreements

From ServiceNow Wiki
Home > Deliver > Planning and Policy > Service Level Management > Service Level Agreements
Jump to: navigation, search


Contents

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.

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.

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.

Image:taskSLA.jpg

2.2.1 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.

2.3 SLA Workflow

The SLA Workflow is a workflow defined in the Graphical 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
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

SLA-application-j11p2.png
  • 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

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:
    IncidentInitial.jpg
  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:
    IncidentMid.jpg
  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:
    IncidentPause.jpg
  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:
    IncidentAfterPause.jpg
  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:
    IncidentBreached.jpg

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.

6 Enhancements

6.1 Aspen Release

The property Compute prior SLA pause time for new, retroactive SLAs (2011 SLA engine only) is available. When enabled, this property calculates the pause time when a retroactive SLA is attached.

For example: if a retroactive SLA attaches to an incident one hour after its creation and meets the pause conditions for half an hour, then the elapsed time is half an hour rather than the full hour.

Note
Note: This property is only used with audited tables. Tables which are not audited ignore the pause time before the creation of the record.
Was this article helpful?
Yes, I found what I needed
No, I need more assistance
Views
Personal tools