Service Level Management

You can activate the SLA Breakdowns plugin (com.snc.sla.breakdowns) if you have the admin role. This plugin includes demo data and activates related plugins if they are not already active.

You can activate the Service Level Management plugin (com.snc.sla) if you have the admin role. This plugin includes demo data and activates related plugins if they are not already active.

You can activate the Service Level Management - SLA Timer Config API plugin (com.sn_slm_timer) if you have the admin role.

Configure SLAs to define a set amount of time for a task to reach a certain condition, to ensure that incidents are closed or resolved according to the expectations set for customers.

You can create custom SLA condition class and condition rule records.

If you are on an earlier version of the SLA engine, you can upgrade to the 2011 engine to make use of the complete service level management functionality.

Previously, only a single SLA could be attached to a task via the Escalation engine. The information for the SLA was stored in the task table using the SLA Due, Made SLA, and Escalation fields.

Migrate SLA processing from the escalations engine to use the service level management functionality.

SLA Administrators can repair SLA records to ensure SLA timing and duration information is accurate.

SLA has default scheduled jobs to regularly refresh the time calculations on each active task SLA.

SLA condition rules control how the different conditions you define in an SLA definition are combined to determine whether an SLA should attach, pause, complete, reattach, or cancel.

SLA conditions determine when a task SLA record is attached, paused, resumed, reset, canceled, and completed.

An SLA definition is used to create and progress SLAs, enabling you to use an SLA system for your organization's tasks.

You can select one of two SLA duration types to define the length of time within which a task must be completed before the SLA is breached.

You can view the details for every task SLA record created for a task.

SLA sends notifications at certain events defined in the workflow.

The SLA engine performs two passes to evaluate SLA definitions and their conditions based on a task.

Schedules within SLA enable you to define the time periods during which the SLAs accumulate business time.

The SLA timeline is a feature of the Service Level Management application. The SLA timeline detail helps you understand the progress of an SLA. The timeline provides detailed insight to the task updates which triggered stage changes during the life cycle of a task SLA.

Schedules have an impact on the duration specified in an SLA definition.

You can specify the geographical time zone that is used for schedule calculation.

You can configure various aspects of Service Level Management based on the specific requirements of your organization.

You can define an SLA breakdown to capture, store, and relay detailed task ownership information and duration for all task SLA records related to a specific task (incident). SLA breakdown is configurable and you can configure it on the basis of a specific SLA definition.

A new table of SLA contracts is provided through the Service Level Management Service Contracts module. These contracts group together SLAs that relate to a single vendor or customer, as well as the CIs, locations, groups, users, and child contracts that are related to the contract.

Domain separation is supported in Service Level Management. Domain separation enables you to separate data, processes, and administrative tasks into logical groupings called domains. You can control several aspects of this separation, including which users can see and access data.

Use Service Level Management across your organization to monitor and manage the quality of the services.

Use the flow actions to send SLA notifications when the duration specified in the SLA definition is crossed.

Several types of components are installed with the SLA breakdown definitions.

The Service Level Management - SLA Timer Config API (com.sn_slm_timer) plugin installs the admin role.

Use the ITSM Service Level Management agentic workflows to manage and complete tasks autonomously.

Validate that Service Level Management still works after you make any configuration change such as apply an upgrade or develop an application. Copy and customize these quick start tests to pass when using your instance-specific data.

Prior to adding custom business rules to the task SLA table, you must consider a few points regarding the processing and calculation of the task SLA based on your organization’s needs.

Task SLA records contain two sets of timing information: Actual elapsed and Business elapsed.

Activating the Service Level Management plugin adds or modifies these components: tables, properties, UI actions, UI policies, script includes, client scripts, business rules, email notifications, scheduled jobs, and workflows.

Administrators can set SLA repair properties and view repair logs.

When SLA timeline is activated, script includes are installed.

SLAs are calculated and assessed by a business rule and scheduled jobs that run in the background.

The SLAConditionBase script include implements the default SLA transitions.

The SLAConditionSimple script include provides an example modification of default SLA condition processing.

SLA records pass through a series of transitions during processing.

The Task SLA [task_sla] table stores Task SLA records for the SLAs attached to particular tasks.

The ServiceNow Service Level Management (SLM) application facilitates you to oversee and control the services within the organization.

Reference sections provide additional information about components installed with Service Level Management.

The ServiceNow Service Level Management (SLM) application helps to gather service requirements as well as monitor and report with regards to agreed service levels (SLAs).

Using SLA breakdown, the service owner or service desk manager can see detailed task ownership and SLA duration related data for any task SLA record associated with a task. This helps determine which teams and users are contributing to SLA compliance.

You can activate one or more of the Service Level Management plugins if they are not already active. Some plugins include demo data.

This example demonstrates how to use the SLA timeline to determine the business schedules and business percentage time related to a task SLA.

Configure the SLA timer to determine which task SLA must be displayed as part of the timer component.

When SLA Timer Config API is activated, script includes are installed.

Use the SLA timer component to track the amount of time that is required to complete the task as defined by the matching SLA definition.

You can activate the SLA timeline plugin (com.snc.sla.timeline) if you have the admin role. This plugin activates related plugins if they are not already active.

You can add custom business rules to your SLAs.

You can configure the SLA engine, logging, and repair properties based on the requirements within your organization.

You must replicate the default SLA record as a new SLA definition.

Create SLA definitions to set the conditions under which SLAs attach, pause, stop, and reset on task records. Use them to track and enforce service commitments across your organization.

You can create custom SLA condition rules to determine whether an SLA should attach, pause, complete, reattach, or cancel. SLA condition classes contain script to define processing for an SLA condition rule. Create an SLA condition rule after the SLA condition class is defined.

You can globally change the default set of SLA condition rules.

You can change the SLA condition rules for a specific SLA definition.

You can upgrade SLA processing to use the 2011 Engine.

There are several ways to convert the old SLAs to the new Task SLAs.

Escalation engine is replaced with 2011 SLA Engine.

You can repair task SLA records from the Task form, or from the task SLA form for an SLA associated to a Task.

You can repair multiple SLA records from a list of task or SLA records.

By default in the 2011 SLA engine, the SLA processing is performed by the Run SLAs business rule. This business rule runs synchronously and is the suggested configuration.

When business percentages are used for SLA calculations, they are rounded up to two decimal places.

By default when a user opens a task, the SLA timing information for that task is not automatically recalculated.

As work is done on the relevant task, the SLA may change stage appropriately, depending on the information defined for that SLA in the relevant SLA definition.

You can use retroactive start to retain timing information for an SLA when a task record changes. Retroactive pause prevents immediate breaches and notifications when retroactive start is enabled for SLA definitions.

View an SLA timeline to review its details and its progress over time.

Describes how you can understand SLA stage changes using SLA timeline.

Use the Service Level Agreement (SLA) to define a set amount of time for a task to reach a certain condition, to ensure that incidents are closed or resolved according to the expectations set for customers.

When a new SLA Definition is created the SLA Timeline can be used to see how the SLA will behave against existing task records.

You can verify that a task is mapped appropriately with a defined SLA using the SLA timeline. If a task is mapped with the SLA definition, the SLA timeline displays a graphical representation of the progress of the task SLA.

Describes the conditions when an SLA might not trigger as expected.