contract_sla Table — ServiceNow Reference

Table Reference/contract_sla

The contract_sla table stores SLA definitions with breach and warning thresholds, business calendars, and pause conditions for ITSM processes. This ITSM module table is the configuration backbone for all SLA calculations — records here define how task_sla records behave when attached to incidents, requests, and other tasks.

What This Table Is

The contract_sla table stores SLA definitions that control how ServiceNow measures and enforces service level agreements across ITSM processes. Each record defines breach times, warning thresholds, business calendars, and pause conditions that get applied when SLA workflows attach task_sla records to incidents, service requests, changes, and other task-based records.

Owned by the ITSM module, this table supports the complete SLA lifecycle from definition through breach notification. Each SLA definition can specify different duration targets for different conditions (priority, category, assignment group combinations) and controls whether SLAs pause when tasks are pending customer response or in other specified states.

The table extends sys_metadata and works as a configuration table — you rarely create records programmatically, instead querying existing SLA definitions to understand which apply to specific task conditions. Related tables include contract_sla_breakdown for condition-specific timing rules and task_sla for the runtime SLA instances that reference these definitions.

In large enterprises, expect 50-200 SLA definition records covering different service offerings, with each SLA definition potentially spawning thousands of task_sla instances daily. The table performs well for queries since record volume stays manageable, but watch for complex condition evaluations during SLA attachment workflows.

When You'll Script Against This Table

You'll query contract_sla most often in Business Rules that evaluate SLA applicability, Script Includes building SLA management utilities, and Scheduled Jobs generating SLA performance reports. Custom SLA attachment logic, SLA definition validation workflows, and integrations that need to understand service level commitments all hit this table regularly.

Users need sla_admin role for full CRUD operations, but most scripting contexts query with elevated privileges. The itil role provides read access for viewing SLA definitions and their associated breakdown rules.

Query active SLAs by table and condition to determine which apply to new tasks
Validate SLA configuration changes before deployment using automated checks
Build SLA selection logic in custom workflows that need to apply non-standard SLA rules
Generate reports showing SLA definitions and their configured breach/warning times
Sync SLA definitions with external service management tools during integrations
Clone or bulk-modify SLA definitions during service catalog or organizational changes
Audit SLA configuration compliance against corporate service level commitments

Table Gotchas

⚠️

The duration field stores time in seconds but displays in day/hour/minute format on forms. Always convert your calculations to seconds when comparing against duration values programmatically.

⚠️

SLA definitions with complex conditions in the condition field can cause performance issues during SLA attachment. Test condition evaluation performance with realistic task volumes before deploying complex conditional logic.

The active field doesn't prevent SLA attachment — inactive SLAs can still be manually attached to tasks through workflows or scripts
Business calendar changes don't automatically recalculate existing task_sla due times — only new SLA attachments use updated calendar settings
The collection field accepts table names but doesn't enforce referential integrity — you can reference non-existent tables without validation errors

⚠️

Pause conditions in the pause_condition field run against every task state change. Expensive queries or complex logic here can impact task update performance across your entire instance.

SLA workflows can create multiple task_sla records per contract_sla definition if conditions change during task lifecycle — one SLA definition can spawn multiple active SLA instances

Free Newsletter

Enjoying this? Get one deep-dive per week.

Join 1,000+ ServiceNow pros — scripts, GlideRecord patterns, Flow Designer techniques, and career moves. Free.

The table extends sys_metadata, inheriting standard metadata fields and behaviors. Most directly related is contract_sla_breakdown, which stores the condition-specific timing rules that define different duration targets based on priority, category, or other task attributes. Each contract_sla record typically has multiple breakdown records defining escalation tiers.

You'll constantly join with task_sla when analyzing SLA performance, since task_sla records reference contract_sla definitions and store the runtime state (due dates, breach times, pause durations). The cmn_schedule table provides the business calendars that SLA calculations use, while sys_user_group and cmdb_ci_service often appear in SLA condition logic for group-based or service-specific SLA selection.

Since the collection field specifies which tables the SLA applies to, you'll frequently query alongside incident, sc_req_item, change_request, and other task-extended tables when building reports or validating SLA coverage across different ITSM processes.

Chrome Extension

Sourdough: ServiceNow Monitoring and Analytics

A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.

Instance HealthGraphs & ChartsAPI HealthDeveloper ToolsQuick SearchInstance Switcher

Add to Chrome

Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.

Overview

Tasks

CMDB

API

Metrics

Monitor

Internals

Instance:sourdoughdev·Version:Yokohama

Instance StateONLINE

System StatusFully Operational

Session Timeout90 minutes

Logged-In Sessions2 (20 active)

Build Nameyokohama-12-18-2024_p1

IP Address10.159.128.43

Instance HealthHealth Score: 90%

🔥 5dSourdough (Chrome Plugin)Dark Mode

Key Fields

Column	Type	Label	Notes
name	string	Name	Display name for the SLA definition. Must be unique per table — you can't have duplicate SLA names for the same collection.
active	boolean	Active	Controls SLA visibility in selection lists, but doesn't prevent programmatic attachment. Inactive SLAs can still be manually applied through scripts or workflows.
collection	string	Table	Target table name where this SLA applies (incident, sc_req_item, etc.). No referential integrity checking — invalid table names are accepted.
condition	string	Condition	Encoded query string defining when this SLA applies to records. Complex conditions here can impact SLA attachment performance significantly.
duration	glide_duration	Duration	Default SLA duration in seconds, though breakdown records typically override this. Forms display in day/hour/minute format but store as total seconds.
schedule	reference	Schedule	References cmn_schedule table for business calendar. Changes to schedules don't recalculate existing task_sla due times, only affect new attachments.
pause_condition	string	Pause condition	Query condition that pauses SLA timers when true. Evaluates on every task state change, so expensive queries here impact overall task performance.
start_condition	string	Start condition	Condition that must be met before SLA timing begins. Empty means SLA starts immediately when attached to a task record.
stop_condition	string	Stop condition	Condition that stops SLA timing permanently when met. Different from pause_condition — stopped SLAs don't resume even if condition becomes false.
reset_condition	string	Reset condition	Condition that resets SLA timing back to start when met. Commonly used for SLAs that restart when tasks are reassigned or reopened.
workflow	reference	Workflow	References wf_workflow table for custom SLA processing logic. Most SLAs use the standard OOB workflow, custom workflows are for specialized timing rules.
enable_breakdown	boolean	Enable breakdown	Activates the breakdown rules system allowing different durations based on conditions. When true, contract_sla_breakdown records control actual timing.
retroactive	boolean	Retroactive	Whether this SLA applies to existing records when activated. False means only new records get this SLA, true includes pre-existing matching records.
relative_duration_works_on	choice	Relative duration works on	Defines the field used for relative duration calculations. Options include opened_at, sys_created_on, or other datetime fields on the target table.
timezone	choice	Time zone	Time zone for SLA calculations when different from system default. Affects due date calculations but not pause/resume logic timing.
sla_type	choice	Type	SLA category for reporting and organization. Values like Resolution, Response, etc. — purely descriptive, doesn't affect timing calculations.

Common Queries

Get all active SLA definitions

// Most basic query — what every developer tries first
var gr = new GlideRecord('contract_sla');
gr.addQuery('active', true);
gr.query();

while (gr.next()) {
    // Active SLAs available for attachment
    gs.info('SLA: ' + gr.name + ' for table: ' + gr.collection);
}

Find SLAs for incident table with specific schedule

// Real-world: finding incident SLAs with business hours schedule
var gr = new GlideRecord('contract_sla');
gr.addQuery('active', true);
gr.addQuery('collection', 'incident');
gr.addQuery('schedule.name', 'Business Hours'); // Join to cmn_schedule
gr.query();

while (gr.next()) {
    gs.info('Incident SLA: ' + gr.name + ' uses schedule: ' + gr.schedule.name);
}

Get SLAs that apply to high priority incidents

// Business scenario: checking which SLAs trigger for P1 incidents
var gr = new GlideRecord('contract_sla');
gr.addQuery('active', true);
gr.addQuery('collection', 'incident');
gr.addQuery('condition', 'CONTAINS', 'priority=1'); // Simple condition check
gr.query();

// Note: This is a basic check, real condition evaluation needs GlideFilter
while (gr.next()) {
    gs.info('P1 SLA found: ' + gr.name);
}

Count active SLAs by table type

// Aggregate count for SLA coverage analysis
var ga = new GlideAggregate('contract_sla');
ga.addQuery('active', true);
ga.groupBy('collection');
ga.addAggregate('COUNT');
ga.query();

while (ga.next()) {
    var table = ga.collection.toString();
    var count = ga.getAggregate('COUNT');
    gs.info('Table ' + table + ' has ' + count + ' active SLAs');
}

Wrong way vs right way to check SLA applicability

// WRONG: checking condition field with simple string match
// var gr = new GlideRecord('contract_sla');
// gr.addQuery('condition', 'CONTAINS', 'priority=1'); // Unreliable!

// RIGHT: use GlideFilter to properly evaluate encoded conditions
var testRecord = new GlideRecord('incident');
testRecord.get('some_sys_id');

var gr = new GlideRecord('contract_sla');
gr.addQuery('collection', 'incident');
while (gr.next()) {
    // Proper condition evaluation against actual record
    if (GlideFilter.checkRecord(testRecord, gr.condition)) {
        gs.info('SLA applies: ' + gr.name);
    }
}

Test Your Knowledge

Quick 3-question quiz — see how your ServiceNow skills stack up.

Question 1 of 3Performance

A list view on a table with millions of records is slow. Best fix?

Select an answer to continue

contract_sla