SLA definitions in practice
Quick answer
Build SLAs that measure the right thing: conditions, schedules, pause behaviour and repair reporting.
Key takeaways
- Task SLA records hold the clock and the reporting data
- Pause behaviour must be agreed before go live
- Schedules make business hours meaningful
- Overlapping conditions attach two SLAs to one task
Anatomy of an SLA
A definition holds start, pause, stop and reset conditions, a duration, and a schedule. The task SLA record created from it holds the running clock, and that is what you report on.
Pause conditions
Most disputes come from pause behaviour. Decide explicitly whether awaiting customer stops the clock, and get that agreed with the business before go live, because retrofitting it makes historical reporting inconsistent.
Reporting and repair
Task SLA records are the reporting source.
- Report on the task_sla table, not on incident fields
- Use the SLA repair job carefully, it recalculates and can rewrite history
- Set retroactive start when the clock should begin at record creation
- Watch for SLAs attaching twice, that is a condition overlap in the definitions
Want to learn this properly?
Our live, instructor-led ServiceNow Training covers this hands-on, with real projects and a certification path.
Check your understanding
Which table should SLA reports use?
- A. incident
- B. task_sla
- C. sys_journal_field
- D. sla
Show answer
B. task_sla
task_sla holds the actual running and completed clocks.
What most often causes SLA disputes?
- A. Schedule colours
- B. Pause condition behaviour
- C. Report titles
- D. Notification wording
Show answer
B. Pause condition behaviour
Whether the clock pauses while awaiting the customer is the classic argument.