SLA Retroactiveness

SLA defines an amount of time for which a task needs to be completed like resolving an Incident or fulfilling a Service Catalog order. While the SLA is running, one can perform actions at specified times like sending notifications to remind assignee about the task or informing a supervisor/manager if the SLA has expired.

One can define SLAs for lots of different tasks like Incidents, Problems, Changes, or Service Catalog Orders.

SLA gets attached and runs based on predefined conditions like when it should start, when it should be paused and resume, when it will stop and reset to its original state. These conditions are defined in SLA definition module and stored in contract_sla table.


  1. SLA without Retroactive Start

When a task record changes, a new SLA may get attached with a new set of timing information. This can be useful while reassigning an incident to another group and to attach a new SLA record with timing information.

For example, SLA start condition: priority is critical and assignment group is Network

When the SLA conditions are met, the SLA with predefined duration of 24 hours gets attached to the task.

Let’s change the assignment group to Database so that the SLA for Database group with critical priority incident will get attached to the task.

After changing the assignment group from Network to Database the SLA with Priority – critical and assignment group – Database conditions will get attached to the incident task.

he new assignment group i.e the database group will consume its whole duration of 24 hours which is predefined in our SLA definition.

  1. SLA with Retroactive start

Let’s see the result when set the ‘Retroactive start’ field to true and ‘Set start to’ field to ‘created’ in the SLA definition which will get attached to the incident when the priority is critical and assignment group is Database.

From above screenshot, notice that the SLA which was running when priority was critical and assignment group was Network, takes complete 24 hours duration.

After changing the assignment group to Database the new SLA having the duration of 24 hours get attached to the incident but considers the timing information from when the incident was created. In the new SLA with checked Retroactive Start, SLA will overlook the Incident’s Assignment group change time and consider only the Incident creation time.

If SLA’s Retroactive is false (unchecked), the new SLA starts on the date and time when it is attached to the incident.

One can use Retroactive Start to ensure that the SLA timing is adjusted retroactively (taking effect from the date in past) to count from when the incident was first created, instead from when the incident’s assignment group is changed.

Apart from task created date, one can also set a different triggering event for an SLA in Set start to field that is attached to a task after the task was created.

  1. SLA with Retroactive Pause

If checked, it ensures that the new task SLA record gets any pause time that would have been accumulated during the period between the retroactive start time and current time. The main functionality of Retroactive Pause is that it increases the breach time with the appropriate amount.