task_sla Table — ServiceNow Reference

Table Reference/task_sla

The task_sla table stores SLA tracking records automatically created by ServiceNow's SLA engine for individual task records. Owned by the ITSM module, this table tracks breach percentages, pause states, and duration calculations. The critical thing to know: these records are managed by the SLA engine — direct manipulation can break SLA calculations.

What This Table Is

The task_sla table stores individual SLA tracking records that monitor service level agreement compliance for task records. Each record represents one SLA definition applied to one task, tracking breach percentage, pause state, duration calculations, and breach timestamps. The SLA engine automatically creates these records when tasks are inserted or updated based on SLA definition conditions.

This table is owned by the ITSM module and serves as the operational layer of ServiceNow's SLA framework. While contract_sla defines SLA rules and task_sla_controller manages pause/resume logic, task_sla records track the actual progress and breach calculations for each SLA instance.

The task_sla table does not extend any parent table — it's a standalone table with a reference to task records. No tables extend task_sla directly, though some scoped applications create custom SLA tracking tables that mirror this structure.

In large enterprises, this table grows rapidly — expect 500K+ records annually in high-volume environments. Each incident, request, change, or problem can generate multiple task_sla records if multiple SLA definitions apply. Performance degrades quickly without proper indexing on task, stage, and sla fields.

When You'll Script Against This Table

You'll typically script against task_sla in Business Rules on task tables (incident, request, change) to read SLA status for notifications or field updates. Script Includes and Scheduled Jobs query this table for SLA reporting and dashboard data. Background scripts commonly hit this table for data fixes or bulk SLA recalculations.

Access requires sla_admin role for full CRUD operations. The itil role provides read access for most SLA fields. Business Rules run with elevated privileges but client scripts respect user permissions.

Common scripting patterns:

Query active SLA records by task reference to display breach status on forms
Check percentage field values for escalation triggers (usually >80% or >100%)
Filter by stage field ('in_progress', 'paused', 'completed', 'cancelled') for workflow logic
Read planned_end_time for due date calculations and calendar integrations
Aggregate breach counts by assignment group or category for management reporting
Update business_pause field for custom pause conditions (with extreme caution)
Join with contract_sla records to access SLA definition details and thresholds

Table Gotchas

⚠️

Never directly insert, update, or delete task_sla records unless you fully understand SLA engine behavior. The SLA engine recalculates duration, percentage, and breach times based on schedule and pause logic — manual changes can create inconsistent data.

The percentage field can exceed 100 — values >100 indicate breached SLAs, with 150 meaning 50% over the time limit
The stage field uses choice values, not integers: 'in_progress', 'paused', 'completed', 'cancelled' — string comparisons only

⚠️

Duration calculations depend on schedule records (cmn_schedule). Querying duration without considering schedule gaps and business hours will produce incorrect SLA compliance calculations.

Multiple SLA records can exist for the same task — filter by active=true to avoid counting historical or cancelled SLA instances
The business_pause field only affects future calculations — changing it doesn't retroactively adjust existing duration values

⚠️

Querying task_sla without proper indexing kills performance. Always include task, stage, or sla reference fields in your queries. Avoid queries filtering solely on percentage or duration — these fields aren't indexed.

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 task table is the primary relationship — each task_sla record references one task record via the task field. You'll frequently join these tables to display SLA status on incident, request, change, or problem forms. The contract_sla table defines the SLA rules that generate task_sla tracking records.

The task_sla_controller table manages pause/resume conditions and links to task_sla records. Developers query both tables together when building custom pause logic or debugging SLA timing issues. The cmn_schedule table provides business hours calculations referenced by SLA duration logic.

You'll also work with sys_user and sys_user_group tables when building SLA reports grouped by assignee or assignment group. The cmdb_ci table becomes relevant for SLA reporting by affected configuration items or services.

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
task	reference	Task	References the task record this SLA applies to. This is your primary join field — always indexed and required for efficient queries.
sla	reference	SLA Definition	References the contract_sla record that defines this SLA's rules. Use this to access SLA name, duration, and threshold settings.
stage	string	Stage	Current SLA stage: 'in_progress', 'paused', 'completed', 'cancelled'. String values only — no integer comparisons. Critical for filtering active SLAs.
percentage	decimal	Percentage	Percentage of SLA time consumed. Values >100 indicate breached SLAs. Calculated by SLA engine — don't modify directly.
active	boolean	Active	Indicates if this SLA instance is currently active. Multiple SLA records can exist per task — filter by active=true for current status.
planned_end_time	glide_date_time	Planned End Time	When this SLA is scheduled to breach. Calculated based on schedule and pause conditions. Use for due date displays and escalation triggers.
start_time	glide_date_time	Start Time	When SLA tracking began for this record. Usually matches task creation time but can differ based on SLA start conditions.
end_time	glide_date_time	End Time	When SLA tracking ended (completion or cancellation). Empty for active SLAs. Use to calculate actual duration for reporting.
business_pause	boolean	Business Pause	Manual pause flag that stops SLA calculations. Changes only affect future calculations — doesn't retroactively adjust duration.
pause_time	glide_date_time	Pause Time	Total time this SLA has been paused (in seconds). Includes both business_pause and automatic pause conditions. Read-only field.
duration	glide_duration	Duration	Actual elapsed time for this SLA in business hours. Excludes pause time. Calculated by SLA engine using schedule definitions.
business_duration	glide_duration	Business Duration	Elapsed business time excluding weekends and holidays. Based on the schedule associated with the SLA definition.
schedule	reference	Schedule	References cmn_schedule record used for business hours calculations. Inherited from SLA definition but can be overridden per instance.
timezone	string	Time Zone	Time zone for SLA calculations. Usually inherited from schedule or user preferences. Affects planned_end_time calculations.
has_breached	boolean	Has Breached	True if this SLA has exceeded its time limit (percentage >= 100). Remains true even after task completion for reporting purposes.
breach_time	glide_date_time	Breach Time	Timestamp when this SLA first breached. Empty for non-breached SLAs. Critical for breach duration reporting and escalation tracking.

Common Queries

Get all active SLA records for a specific task

// Most basic query — what every developer tries first
var gr = new GlideRecord('task_sla');
gr.addQuery('task', current.sys_id); // or specific task sys_id
gr.addQuery('active', true);
gr.query();

while (gr.next()) {
    gs.info('SLA: ' + gr.sla.getDisplayValue() + 
           ', Stage: ' + gr.stage + 
           ', Percentage: ' + gr.percentage);
}

Find breached SLAs for incidents assigned to a specific group

// Join task_sla with incident table for business scenarios
var gr = new GlideRecord('task_sla');
gr.addQuery('stage', 'in_progress');
gr.addQuery('has_breached', true);
// Join condition to incident table
gr.addJoinQuery('incident', 'task', 'sys_id')
  .addCondition('assignment_group', incident_group_sys_id);
gr.query();

while (gr.next()) {
    // Process breached SLAs for escalation
    gs.info('Breached SLA on: ' + gr.task.number);
}

Get SLAs approaching breach threshold for proactive notifications

// Real-world scenario: find SLAs at 80%+ for escalation
var gr = new GlideRecord('task_sla');
gr.addQuery('stage', 'in_progress');
gr.addQuery('percentage', '>=', 80);
gr.addQuery('percentage', '<', 100); // not yet breached
gr.addQuery('active', true);
gr.orderByDesc('percentage');
gr.query();

while (gr.next()) {
    // Send warning notifications before breach
    gs.info('SLA at ' + gr.percentage + '% for ' + gr.task.number);
}

Count breached SLAs by assignment group for reporting

// Aggregate count using GlideAggregate for dashboard metrics
var agg = new GlideAggregate('task_sla');
agg.addQuery('has_breached', true);
agg.addQuery('stage', 'completed');
// Join to get assignment group from task
agg.addAggregate('COUNT');
agg.groupBy('task.assignment_group');
agg.query();

while (agg.next()) {
    var group = agg.getValue('task.assignment_group');
    var count = agg.getAggregate('COUNT');
    gs.info('Group: ' + group + ' Breaches: ' + count);
}

Wrong way vs right way to check SLA completion

// WRONG: checking end_time field existence
// var gr = new GlideRecord('task_sla');
// gr.addQuery('end_time', '!=', '');

// RIGHT: check stage field for completion status
var gr = new GlideRecord('task_sla');
gr.addQuery('stage', 'completed');
gr.addQuery('task', current.sys_id);
gr.query();

// Why: end_time can be empty for cancelled SLAs
// stage field is the authoritative completion indicator

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

task_sla