Service Level Agreement (SLA) for ServiceNow

This blog is a one-stop shop for SLA. That is the reason I am writing this article, so that we could have a consolidated information about SLAs in servicenow. I have picked up these points from docs, learning content and information available on community. This article would help you have a general idea about important terms and terminologies used in SLA in servicenow. It would also help you with SLA topics for your interviews and tests.

What is SLA and SLA Definition?

In general terms, A service-level agreement (SLA) defines the level of service you expect from a vendor, laying out the metrics by which service is measured, as well as remedies or penalties should agreed-on service levels not be achieved.
SLA is a feature of Service Level Management (SLM) application in servicenow.
SLA Definition is used to define a specific set of criteria that would result in an SLA being generated with parameters like Table, Duration, Schedule, Conditions etc.

Roles in SLA:

sla_admin: Provides full SLM administrative rights.Users that possess the sla_admin role can configure SLM properties, run SLA repair, view the SLA, Overview dashboard, and manage SLA definitions. They may associate existing workflows or schedules to SLA.
sla_manager: Lets users define SLA definitions, view SLA repair logs, and view the SLA Overview dashboard.

Targets in SLA:

Respond – Response SLA is calculated from the time the incident is created and assigned to a group till it is assigned to someone from the group. It is the time taken to acknowledge the ticket.
Resolution – Resolution SLA is calculated from the time the incident is created till the time the incident is resolved.

Types of SLA in SLA Definition:

SLA : A Service Level Agreement (SLA) is a contract between an internal service provider and an external end customer. Service Level Agreements define the range and quality of the covered services. Within the Service Desk, SLAs especially define the time spans in which tickets must be accepted and solved in order to avoid escalation.
OLA: An Operation Level Agreement (OLA) is an agreement between an internal service provider and an internal customer. Operation Level Agreements define the range and quality of the covered services. It’s an agreement between the internal IT departments (e.g., Network Management and IT Operations ).
Underpinning Contract: An Underpinning Contract (UC) is a contract between an external provider and an internal end customer. Underpinning Contracts define the range and scope of the covered services.

Types of SLA’s in terms of ITIL:

Customer-based SLA: This type of agreement is used for individual customers and comprises all relevant services that a client may need, while leveraging only one contract. It contains details regarding the type and quality of service that has been agreed upon. For example, a telecommunication service includes voice calls, messaging and internet services, but that all exists under a single contract.
Service-based SLA: This SLA is a contract that includes one identical type of service for all of its customers. Because the service is limited to one unchanging standard, it is more straightforward and convenient for vendors. For example, using a service-based agreement regarding an IT helpdesk would mean that the same service is valid for all end-users that sign the service-based SLA.
Multi-level SLA: This agreement is customized according to the needs of the end-user company. It allows the user to integrate several conditions into the same system to create a more suitable service. It addresses contracts at the following levels:
- Corporate level: This SLA does not require frequent updates since its issues are typically unchanging. It includes a comprehensive discussion of all the relevant aspects of the agreement, and is applicable to all customers in the end-user organization.
- Customer level: This contract discusses all service issues that are associated with a specific group of customers. However, it does not take into consideration the type of user services.An example of this is when an organization requests that the security level in one of its departments is strengthened. In this situation, the entire company is secured by one security agency but requires that one of its customers in the company is more secure for certain reasons.
- Service level: In this agreement, all aspects that are attributed to a particular service with regard to a customer group are included.

Duration in SLA:

SLA duration defines the length of time within which a task must be completed before the SLA is breached.

User specified duration – Specifies a static duration period, such as 8 hours, along with a business schedule. The Duration field is displayed, enabling you to specify the length of time in days, hours, minutes, and seconds that the SLA must run before it is marked as breached. The number of days specified in the Duration field is converted to 24- hour blocks. Each time that you set a duration, an example breach time information message is displayed at the top of the form. This information assists you in understanding how the breach date is calculated.
Relative Duration – Specifies a duration relative to the start time of the task SLA and is defined using a script. For example, you can select a relative duration such as Breach on Due Date, End of next business day or Next business day by 4pm. The set of relative durations is defined in the core configuration using script-based duration calculations.

Schedules in SLA:

Schedules within SLA enable you to define the time periods during which the SLAs accumulate business time. Schedules are typically based on the working hours of the resource or departments to whom a task is allocated. Schedules have an impact on the duration specified in an SLA definition. This impact is reflected in the timings that are taken into consideration while calculating an SLA.

You can specify the schedule to be used when creating new task SLAs in the Schedule source field. You can specify one of the following options:

No schedule: If the No Schedule option is selected, the SLA will calculate based on a 24 x 7 schedule.
SLA definition: If the SLA definition option is selected, the Schedule drop-down list appears.
- Schedule: Specify the hours during which the SLA timer runs. These sets of schedules are defined in the core configuration. For example, you can select a schedule of 8-5 weekdays or 8-5 weekdays excluding holidays.
Task table field: This option picks its title from the option selected in the Table field earlier on the SLA Definition form. For example, if Incident is selected in the Table field, then this option appears as Incident field. If the Task table field option is selected, the Schedule source field drop-down list appears.
- Schedule source field: Select the appropriate field from the task such as an incident or problem that will provide the schedule. For example, Configuration item > Schedule.

Conditions in SLA:

Start condition: Enables you to define the conditions under which the SLA will be attached. You can choose the conditions from the When to cancel list under which the SLA will be cancelled.
- Start conditions are not met option: If one or more of the specified start conditions change, then the SLA will be canceled. The Start conditions are not met, the option is selected by default.
- Cancel conditions are met option: The start condition has to be met only once, thereafter the SLA will only cancel when the cancel condition is met. Never option: The SLA will never be canceled.
- Select Retroactive start: If you select the Retroactive start check box, the Set start to field appears offering the date and time fields available on the task type that this SLA definition applies to. For example if you select Retroactive start on a Priority 1 SLA definition and then choose Created in the Set start to field, then the SLA is attached with the start time being the date and time from the Created field on the Incident.
Cancel condition: Enables you to define the conditions under which the SLA will cancel. You can specify the cancel conditions at the same time when you specify the start conditions.
Pause condition: Enables you to define the conditions under which the SLA will suspend increasing elapsed time. You can choose the conditions from the When to resume list under which the SLA will resume increasing elapsed time.
- Pause conditions are not met option: If one or more of the specified pause conditions no longer match, then the elapsed time will continue to increase. The Pause conditions are not met and the option is selected by default.
- Resume conditions are met option: If one or more of the specified resume conditions match, then the elapsed time will continue to increase.
- Resume condition: Enables you to define the conditions under which the SLA will resume increasing elapsed time. You can specify the resume conditions at the same time when you specify the pause conditions.
Stop condition: Enables you to define the conditions under which the SLA completes. If all of the specified stop conditions match, then the task SLA will complete regardless of whether it is breached.
Reset condition: Enables you to define the conditions under which the running SLA will be completed and a new SLA will be attached. For a new SLA to be attached, the start condition must match.
Reset condition also helps to configure SLAs when the value of any specific field on the task record changes, changes to or changes from a specific value in the record.

WorkFlows and Flows for SLA:

You can create and edit workflows with the Workflow Editor. You can create and edit flows using Flow Designer.

The Default SLA Workflow/FLow: Creates the events that send out notifications. For example, it creates an event to send a notification to the user assigned to a task, such as an incident, when the task SLA reaches 50% of its allotted time.
The SLA Notification and Escalation Workflow/Flow: Creates the events that send out notifications. When a task reaches 50% of its allotted SLA duration, a notification is sent to the assignee and the user listed in the Supported by field on the configuration item. At 75% and 100%, a notification is sent to the assignee and the assignee’s manager.

Important Tables associated with SLA:

SLA Definition (‘contract_sla’): is the table where you can create/modify any SLA as per your requirement. So this is the table if you try to create any SLA.
Task SLA (‘task_sla’) : It is the table where you can find the task records against which SLA has been attached. That means, if you create an Incident and that satisfies a SLA start condition (defined in the SLA Definition table) then the SLA will get attached with the Incident. Once it gets attached, you can find that in the Task SLA table.
Incident SLA (‘incident_sla’): It’s basically a database view which stores information about connecting task_sla and incident table. It stores each of the individual SLAs attached to particular incidents.

FAQ’s around SLA’s

What is Retroactive start?: Whenever a new SLA is attached it will calculate start time from SLA created on date time. When we check this flag true it will show one more field in which you can select from when the time should be calculated.
Can SLA have different different workflows?: Yes
Schedule significance in SLA?: Schedule will determine the actual business hours to be considered when calculating SLA business elapsed and left time. For example 8by5 schedule. 8 hours 5 days between 9am to 5pm. Outside this SLA will be paused i.e. the time won’t be considered.
What happens with old SLA when a new SLA is attached ? For example when incident priority changes to p4 from p1 what will happen with P1 SLA: Previous SLA is cancelled and the start time of the new SLA depends on retroactive start.
What is the difference between Actual Time left and Business time left?: Actual time is the 24 x 7 time which is left for the SLA. Business Time depends on the schedule defined in the SLA. E.g. If the schedule is 8-5 Weekdays, then weekends and time outside 8 to 5 will not be considered as business time.
Table where sla are stored for incident: incident_sla table.