The task_sla table creates multiple records per task β€” one for each SLA definition that applies to that task. Most developers expect one active SLA per task, but a single incident can have separate SLAs for resolution time, response time, and custom business metrics all running simultaneously. The stage='in_progress' query finds currently active SLAs, but paused SLAs remain in_progress with a null breach_time β€” a combination that breaks naive implementations that assume active means counting down.

When to use this

  • Building custom SLA dashboards or reports that need breach time and percentage data
  • Business rules that need to react to SLA state changes or approaching breaches
  • Email notifications that include specific SLA timing information
  • Integration endpoints that export task data with current SLA status to external systems
  • Scheduled jobs that need to identify tasks approaching SLA breach thresholds

When NOT to use this

  • Don't use this in client scripts β€” SLA data should be passed via UI policies or GlideAjax calls
  • Don't query task_sla inside loops over task records β€” build a single query with addQuery('task', 'IN', taskIds) instead
  • Don't use this when you only need basic SLA breach status β€” use the sla_due field on the task record instead
  • Don't assume one SLA per task β€” design your consuming code to handle arrays or pick specific SLA types

Key behaviors and gotchas

  • Multiple active SLAs per task are normal β€” incidents commonly have both resolution and response SLAs running concurrently
  • Paused SLAs stay stage='in_progress' but have null breach_time β€” check for this condition to identify paused SLAs
  • The percentage field shows elapsed time as percentage of total SLA duration β€” values over 100 indicate breach
  • Use business_percentage instead of percentage for SLAs with business schedules β€” it excludes non-business hours
  • The has_breached field is a string 'true'/'false', not a boolean β€” compare with string values or convert explicitly
  • SLA definitions can be retroactively applied β€” you may see task_sla records appear on older tasks after SLA configuration changes
  • Domain separation applies β€” users can only see SLA records for tasks in their domain scope
⚠️

Never rely on finding exactly one active SLA per task. Enterprise SLA configurations routinely create multiple concurrent SLAs, and your code will fail unpredictably when it assumes a single result where arrays exist.