Creating & Configuring SLA Definitions

In ServiceNow, SLA configuration focuses on creating rules, targets, and trigger conditions. It helps track performance in ITSM platforms. SLA’s are configured to define a set amount of time for a task to reach a certain condition. It helps ensure that incidents are responded to and resolved within the agreed service targets. 

In this topic, we will be focusing on ServiceNow SLA Definitions, existing ones and the ones you can create. 

Understand Existing SLA Definitions

Before we create SLA definitions, it is important to understand the SLA templates that are structured in SLM. To manage SLM, administrators must navigate to Service Level Management → SLA → SLA Definitions. The existing definitions define the engagement rules and key factors to identify them: 

• Table: Which form does this apply to? (e.g., Incident).
• Duration Type: Is it a user-specified duration (e.g., 2 hours) or relative to a field (e.g., End Date)?
• Schedule: Does it run 24/7 or only 9-5 weekdays?
• Conditions: 
  • Start Condition – When should the SLA begin?
  • Pause Condition – When should the SLA temporarily stop counting?
  • Stop Condition – When should the SLA finish successfully?

Remember to use consistent naming conventions like “Incident – P1 Resolution – 4 Hour”.

Creating New SLA Definition for Incident Table

To create a new SLA definition for the incident table, there are a few steps one must follow: 

1. Move to Service Level Management. 
2. Navigate to SLA Definitions → New.
3. Fill out the SLA Definition form details, including: 

• Name: Give it a descriptive name (e.g., “P2 – Corporate Resolution”).
• Table: Select Incident.
• Workflow/Flow: Select the automation for notifications (e.g., “Default SLA Workflow”).
• Duration: Set the time (e.g., 8 Hours).
• Schedule: Select a schedule (e.g., “8-5 Weekdays”).
• Start Condition: Priority is 2 – High AND Active is True.
• Pause Condition: State is Awaiting User Info OR State is Awaiting Vendor.
• Stop Condition: State is Resolved OR State is Closed.

Note: Be careful creating definitions that overlap. If you have a generic “All Incidents” SLA and a specific “P1 Incident” SLA, a P1 ticket might get both attached unless you filter the generic one to exclude P1s.

SLA Targets

Every SLA definition requires you to set the Target, which defines the exact time allowed to respond to or resolve a task.The specific metrics are: 

1. Response: Tracks how quickly an assignment group acknowledges or begins working on a ticket (e.g., changing status from New to In Progress).
2. Resolution: Tracks the complete lifecycle duration until the issue is entirely fixed or marked resolved. Time from “New” status to “Resolved”.

In the Definition form, use the “Target” field (Response/Resolution) to classify the SLA. This helps in reporting.

Importance of Retroactive Start and Pause

ServiceNow Retroactive Start and Pause conditions ensure that SLAs reflect historical timeline events rather than the exact moment the SLA engine attaches to a record. 

• Retroactive Start: This setting allows the SLA to calculate time based on when the ticket was created, not when the SLA attached.
• Retroactive Pause: If Retroactive Start is on, this calculates any pause time that occurred before the SLA attached.

Retroactive Start can be used when the SLA should account for time that elapsed before the SLA condition was evaluated or before the Task SLA was created. Whether it should be enabled depends on the SLA design and business requirement. 

What’s Next? 

Apart from configuring the SLA definitions, it is important to understand how to schedule, calculate, and track the SLAs.