Determining how SLAs are attached to records

This article will review how the SLA engine attaches SLAs to records and the rules that control when/if an SLA is attached.

Procedure

Understanding how the SLA engine attaches particular SLAs to records and the way that the SLAs are created, cancelled, and paused can seem complex. There are five basic rules that govern their behavior:

• If the start condition evaluates to true, the stop condition evaluates to true simultaneously, and the task_sla record does not exist, the system does not attach an SLA (no task_sla record is created)
• If the start condition evaluates to true, the stop condition evaluates to false, and the task_sla record does not exist, the system attaches a new SLA (creates the task_sla record)
• If the pause condition evaluates to true also, the task_sla is put into the Paused stage - otherwise, it is put into the In Progress stage
• If the task_sla record exists, and the stop condition evaluates to true, the task_sla record is marked either Achieved or Breached (based on if the has_breached flag was set in the task_sla record)
• If the task_sla record exists, the start condition evaluates to false, and the stop condition evaluates to false, the task_sla is marked Cancelled (it no longer applies) - the pause condition is not considered for this cancelled situation

Also keep in mind that you want the start condition to remain true throughout the SLA until closure. The start condition should not change during the SLAs progress, such as an incident state. Note that the base system (out of box) examples use the Active field as part of the condition that remains true in an incident until closure.

For more information on SLAs, see the following pages in the product documentation:

Configure SLAs
SLA Definition