Why Your Response SLA Might Never Start (And Why SLAConditionSimple Fixes It)

One of the lesser-known behaviours of ServiceNow Service Level Management is how SLA conditions are evaluated. This can lead to response SLAs silently failing to attach, resulting in inaccurate reporting and artificially high SLA performance.

Fortunately, ServiceNow provides an out-of-box alternative condition engine, SLAConditionSimple, specifically designed to address this scenario.

The Problem

Most response SLAs are configured similarly to this:

Start Condition

• Active = true
• Priority = 4

Stop Condition

• Assigned to is not empty

The example below is taken from a standard response SLA definition.

At first glance this appears perfectly reasonable:

• When an Incident is created, start the response SLA.
• When someone is assigned, stop the response SLA.

However, this is not what always happens.

Understanding the Default SLA Engine

The default SLA condition engine (SLAConditionBase) evaluates conditions in this order:

1. Stop
2. Pause
3. Start

Importantly, the Start condition is continuously evaluated, not just when the SLA first attaches.

This means the Start condition is effectively a "keep running" condition rather than simply an entry point.

ServiceNow documents this evaluation order because overlapping conditions can prevent an SLA from ever attaching.

The Real World Example

Imagine a Service Desk analyst answers the phone.

They create the Incident and immediately assign it to themselves before saving.

At the point the record is inserted:

Active = true
Priority = 4
Assigned to = John Doe

Both conditions are already true.

Start Condition   ✓
Stop Condition    ✓

Because the default engine evaluates Stop before Start, ServiceNow considers the SLA immediately complete before it has ever attached.

Result:

• No Task SLA record is created
• No response time is measured
• The interaction disappears from SLA reporting

The analyst responded instantly, but there is no evidence that the response SLA ever existed.

Why This Matters

This behaviour commonly affects:

• Phone calls
• Walk-up support
• Service Desk analysts who self-assign during logging
• Integrations that populate Assigned To immediately

The outcome is under-reporting of response SLAs.

From a reporting perspective it appears that fewer tickets required a response SLA than actually did.

This can inflate SLA compliance because successful responses are never counted.

Enter SLAConditionSimple

ServiceNow ships an alternative condition processor called SLAConditionSimple.

Rather than using the default transition logic, it interprets each condition independently.

The attach logic is extremely simple:

attach: function() {
    return this._conditionMatches(this.sla.start_condition);
}

It only evaluates the Start condition when deciding whether to attach the SLA. The Stop condition is ignored during attachment.

Once attached, normal lifecycle processing continues.

This means the previous example behaves as expected.

Incident Created

Start = True
Stop  = True

↓

Task SLA is created

↓

Immediately completes

Instead of missing the SLA entirely, you now have:

• A Task SLA record
• An accurate response duration (often a few seconds)
• Correct SLA reporting

Visual Comparison

Default SLAConditionBase

Incident Saved
      │
      ▼
Check Stop?
      │
      ├── Yes
      │      │
      │      ▼
      │  No SLA Created
      │
      ▼
Check Start?

SLAConditionSimple

Incident Saved
      │
      ▼
Check Start?
      │
      ├── Yes
      │
      ▼
Create Task SLA
      │
      ▼
Evaluate Stop
      │
      ▼
Complete SLA

When Should You Consider Using It?

SLAConditionSimple is particularly useful for Response SLAs, where the completion event may already exist when the record is first saved.

Typical examples include:

• Assigned To
• First Response
• Work Notes Added
• State changes performed during creation

It is generally less useful for resolution SLAs, where the stop condition usually occurs much later in the ticket lifecycle.

How to Enable It

There are two approaches:

Per SLA

Set the Condition Type on an SLA Definition to Simple.

This allows individual SLAs to use the simplified transition logic without affecting others.

Instance Default

Set the system property:

com.snc.sla.default_conditionclass = SLAConditionSimple

This causes new SLA definitions that do not specify a condition class to use SLAConditionSimple by default.

Things to Consider

SLAConditionSimple is not a replacement for the default engine in every scenario.

The default implementation provides more advanced transition behaviour for complex Start, Stop, Pause and Reset combinations. ServiceNow recommends using the supplied implementations as examples if further customisation is required.

For most response SLAs, however, SLAConditionSimple provides behaviour that better reflects user expectations by ensuring an SLA is attached whenever the Start condition is met, even if the Stop condition is already true.

Key Takeaway

If your response SLA uses a Stop condition such as Assigned To is not empty, State changes, or First Response, check whether records can satisfy both the Start and Stop conditions during creation.

If they can, the default SLA engine may never create a Task SLA.

Switching that SLA to use SLAConditionSimple ensures the SLA is attached first and then completed, resulting in accurate reporting without changing the underlying business process.