Service Level Agreements (SLA) FAQs
Service Level Agreements (SLA) — FAQs
Questions addressed in this document
1. Why is my SLA not getting attached to the Task record?
Only active SLA definitions are evaluated.
Note: In Geneva and earlier releases the "Active" flag is not displayed on the out of the box (OOB) form layout. The default list layout also does not display the active field. To verify whether your SLA Definitions are set to active, configure the form and list layouts to show the "Active" flag.
An SLA will get attached to a task record only when values on the Task record match the "Start condition" specified in the SLA Definition.
If the values on task record match either the Stop or Cancel conditions, the SLA will not get attached to the task record, even if the Start conditions match.
Note: The "Cancel condition" feature is available only from Helsinki onwards.
Check for any customized before Business Rules on the Task table that might be setting workflow to false. Code will look like:
current.setWorkflow(false);
Comment out current.setWorkflow(false); statements and then test if SLAs are being attached. Setting a workflow to false stops further Business Rules from getting executed, and the SLA Engine depends on the OOB Business Rules "Run SLAs" and "Process SLAs" to evaluate SLA Conditions.
Check if the OOB Business Rules "Run SLAs" and "Process SLAs" on the Task table are active
Check if any custom Query Business Rules are defined on the Task or SLA Definitions table that could be filtering out the records.
A Query Business Rule provides the ability to add additional conditions whenever a table is queried. This might stop the SLA Engine from being able to query the Task or SLA Definition records and could lead to improper evaluation of the SLA Definitions.
Refer to the below screen shot to see how to query for any active Before Query Business Rules.
Note: This issue has been fixed in Helsinki and later releases. Refer to the KB0553527 for complete details. This article also provides a workaround for Geneva and prior releases.
2. Why do I have to refresh the form to see the attached Task SLAs?
Fuji and earlier releases:
Navigate to "Service Level Management -> Administration -> SLA Properties". Check if the property "Run the 2011 SLA engine asynchronously after task insert or update operations." is turned on.
Geneva:
Navigate to "Service Level Management -> Properties -> SLA Engine". Check if the property "Run the 2011 SLA engine asynchronously after task insert or update operations." Is turned on.
Helsinki and later releases:
Navigate to "Service Level Management -> Properties -> SLA Engine". Check if the property "Execute the 2011 SLA engine asynchronously" is turned on or off.
If this property is turned on, the SLA engine will get executed in asynchronous mode. This will create a delay between the Task record being updated and SLA engine execution. This improves the performance of inserts and updates to the Task records, but will require the user to either refresh the task Form or the Task SLAs related list to see the attached SLAs.
3. Why are Task SLA records getting cancelled?
An SLA attached to a task will cancel if the "Start Condition" on the SLA Definition no longer matches. It is important to understand this behaviour to define SLA conditions correctly. The "Start Condition" should be thought of as a condition that must be true for the whole period that you want the SLA to be active. It is not just a condition that has to match at the start.
In Helsinki and later releases, two new fields have been introduced - "When to Cancel" and "Cancel Condition":
The intent of this feature was to provide better control when an SLA gets Canceled.
Note: Refer to ServiceNow documentation for details on how to use "When to Cancel" and "Cancel Condition" fields.
4. What is the difference between "Actual elapsed time" and "Business elapsed time"?
The SLA Engine maintains two sets of elapsed timings on each Task SLA record.
The "Actual" fields contain times that are always calculated on a 24 * 7 basis. These fields indicate the physical time that has elapsed since the Task SLA record was created.
The "Business" fields contain the timings based on the Schedule that is associated with the Task SLA record. Schedules define a set of working or business hours.
Elapsed time example:
On the above Task SLA record we can see that:
- * * The SLA Definition named "Priority 1 resolution (8 hour)" is attached to the Task "INC0010001".
* A schedule named "8-5 weekdays" is associated with this Task SLA.
* Start Time for this Task SLA is 7:30 AM. That is the time when the "Start Condition" defined on the SLA Definition matched with the field values on the Task record.
* Actual elapsed time shows that 1 hour 5 minutes 5 seconds have elapsed. This is the physical time that has elapsed since the Task SLA record was attached to the task record.
* Business elapsed time shows 35 minutes 5 seconds have elapsed. That is because the attached Schedule has business hours specified as 8AM to 5PM. Hence system calculates Business elapsed time starting from 8AM onwards.
Note: When there is no Schedule associated with the Task SLA record:
- * * For Fuji and earlier releases, the Business values will be empty
* For Geneva and later releases, a system property allows you to choose if you want to set the Business values to be the same as the Actual
Note: If your Task SLA has the wrong Schedule:
- * * In Helsinki and later releases, check the setting of the "Schedule Source" field on the SLA Definition record. This controls which Schedule gets attached to the Task SLA record.
- * * In Fuji and earlier releases, go to the SLA Properties module and check the setting of:
5. Why are the "Actual elapsed time" and "Business elapsed time" not correct on the Task SLA record?
The timings and percentages on the Task SLA records are not calculated and updated on a continuous basis as it can create performance overhead in system. The SLA Engine takes a "just-in-time" approach to calculate and update these values, as needed.
These values will get updated in the following scenarios:
- * * When an update to the Task record results in a change of stage on the Task SLA record. Ex: From "Paused" to "In Progress" or from "In Progress" to "Completed"
* When one of the OOB "SLA Update" scheduled jobs run
Note: Paused task SLAs are excluded as there is no time elapsing for these records
These jobs run more frequently when the Task SLA gets closer to its Breach time. For more information refer to ServiceNow documentation Scheduled jobs for SLA.
* If the System Property "glide.sla.calculate_on_display" is set to "true" and the Task SLA record is viewed.
Fuji and earlier releases:
Navigate to "System Properties" table by typing "sys_properties.list" in the navigator search box. Query for the property with name "glide.sla.calculate_on_display".
Geneva:
Navigate to "Service Level Management -> Properties -> SLA Engine". Check for the property "Recalculate Task SLA records when a task's form is displayed (ensures current Task SLA calculations when viewing a task, may increase form load time)".
Helsinki and later releases:
Navigate to "Service Level Management -> Properties -> SLA Engine". Check for the property "Refresh Task SLAs when a Task form is displayed".
Note: When this property is enabled, the Task SLA calculations are refreshed as the form is loading.
- * * When user manually initiates the "Refresh" action on the Task SLA record.
Note: In Fuji and earlier releases this UI action was named "Run SLA Calculation".
6. Why do task SLAs not get updated on refresh in Dashboards / Homepages / Reports?
The timings and percentages on the Task SLA records are not calculated nor updated on a continuous basis as it can create performance overhead in system.
The SLA Engine takes a "just-in-time" approach to calculate and update these values, as needed. Therefore task SLAs data is not supposed to be updated when loaded in any kind of report that may be rendered in Homepages or Dashboards.
A common example that causes confusion is the Homepage refresh timing that can be set to an interval of 5, 15, 30, or 60 minutes (ref here
the refresh timing of the Homepage is not going to calculate/update the task SLAs data in the database. That refresh action is just going to load again the data from the database in order to show a possible new update that has been submitted.
7. Why do my users get a notification that an SLA has reached a certain percentage when the Task SLA record does not reflect this?
The workflow for each Task SLA record maintains its own set of values for determining how much time has elapsed. Workflow uses these values to trigger the notifications to users when an SLA has been in progress for the percentages specified in the SLA Percentage Timer workflow activities.
Workflow maintains its own calculation deliberately so it's not dependent on the values stored in the Task SLA record as these may not be up to date.
There is a known error for this issue which includes a workaround that can be viewed at KB0563889.
Note: This issue has been fixed in Helsinki and later releases. The system now updates the Task SLA record whenever an SLA Percentage Timer activity in the workflow expires.
8. What is the purpose of the "SLA Due", "Made SLA" and "Escalation" fields on the Task record?
The fields "SLA Due", "Made SLA" and "Escalation" are legacy fields that are not used by the 2010 or 2011 versions of the SLA Engine.
Prior to the introduction of the SLA Engine (in the "Fall 2010" release), SLAs were processed by the "Escalation" engine that allowed each Task record to be associated with a single SLA. The fields "SLA Due," "Made SLA," and "Escalation" were maintained by the Escalation engine.
The modern SLA engine improves on the original by allowing multiple SLAs to be tracked against each Task record. Users can understand if a particular Task SLA record has breached by viewing the individual Task SLA records - for the 2010 engine the Stage field will show Breached and in the 2011 engine a new "Has breached" field is used.
The Escalation engine is still present and running in the system as it also supports Inactivity Monitors (click here for more information on Inactivity Monitors).
If you see the legacy fields on Task records being updated, these updates are coming from either the Escalation engine or possibly a customization. However, this does not impact the modern SLA engine in any way. The legacy fields can be ignored. Further, because the values may change unexpectedly, they are not intended for customer use.
9. What is the difference between the "Default" and "Simple" SLA condition rules?
SLA condition rules control how the conditions you define in an SLA definition are combined to determine if an SLA should attach, pause, complete, reattach, or cancel.
For example, the Default SLA Condition rule will only attach a new SLA if the "Start condition" matches and the "Stop condition" does not match.
You can specify the condition rule to use on a per SLA Definition basis but you will need to add the "Condition type" field (which is a reference to the "SLA Condition rules" table) to the form:
If the "Condition type" is blank on an SLA Definition, the SLA Engine will look up the default SLA Condition Rule to use from system property "com.snc.sla.default_conditionclass".
There are two SLA Condition Rules available out-of-the-box - Default and Simple. The table below shows which conditions are checked when determining which actions to process for an SLA. The order the actions are listed in below is also the order the SLA engine evaluates them.
This is important to remember in the situation where the conditions for multiple actions have matched.
For example the conditions for completing and cancelling an SLA have matched - in this case the SLA would be marked as completed as this is evaluated first.
| | Condition Rule | | |
| ---------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Default | Simple | |
| A new SLA will attach when... | Start condition matches_and_Stop condition does not match For Helsinki or later instances, if: 
| An SLA will stop (complete) when... | | |
| An SLA will reattach (reset) when... | Reset condition matchesStart condition matches | |
| An SLA will cancel when... | Stop condition does not match_and_Start condition does not match For Helsinki or later instances, the option selected in "When to cancel" determines what conditions will result in the SLA being cancelled: Start conditions are not met Stop condition does not match_and_ Start condition does not match NeverNo conditions checked as SLA cannot cancelCancel conditions are met | Stop condition does not match_and_Start condition does not match_and_Pause condition does not match Note: for Helsinki or later instances, the new options of never cancelling or matching with a defined Cancel condition cannot be used with the Simple SLA Condition Rule
| An SLA will pause when... | For Helsinki or later instances, if: 
| An SLA will resume when... | Pause condition does not match For Helsinki or later instances, if: 
If the out-of-the-box condition rules do not provide the SLA processing required for your instance, it is possible to create your own condition class (script include) and SLA condition rule record.
For more information on this see the online help topic Extend SLA condition rules.
10. How can I define an SLA that has a Breach time (Planned end time) that is for a user defined time?
It is possible to have an SLA Definition that creates Task SLA's with a Breach time based on a date/time taken from the Task — for example the Due Date field which is available on all Task types.
This can be achieved by creating a Relative Duration which allows you to run a script to determine the SLA's Breach time. You can then select this Relative Duration when defining your SLA Definition to replace the default User defined duration.
NOTE: Pause conditions are not supported for relative durations as these are viewed as providing a fixed date/time when the SLA should be met and as such the Breach time should not change
You can create a new Relative Duration record by going to the Relative Durations module. An example of a script that would set the Breach time on the SLA to the date/time in the Due date field from the Task is:
/* This relative duration script will set the Breach Time of the Task SLA to the value in the "Due date" of the Task.
If the "Due date" field is available on the Task form and editable then this effectively allows the user to specify the
Breach Time of the SLA.
If the Due Date field is empty or in the past, the script will instead set the Breach Time of the SLA to 1 second
after the Start time
*/
(function() {
var startDateMs = calculator.startDateTime.getNumericValue();
var dueDate;
// Work out if "current" is a Task record or Task SLA and then get the "due_date" element from the Task
var tableName = current.getTableName();
if (tableName) {
var baseTableName = GlideDBObjectManager.getAbsoluteBase(tableName);
if (baseTableName == "task")
dueDate = current.getElement("due_date");
else if (baseTableName == "task_sla")
dueDate = current.getElement("task.due_date");
}
// if we've got a "due_date" and it's after our SLA's Start time then use it
// otherwise we'll have to default to the same as Start Time plus 1 second (i.e. instant breach of SLA)
if (dueDate && !dueDate.nil() && dueDate.dateNumericValue() > startDateMs)
dueDate = dueDate.getGlideObject();
else {
dueDate = new GlideDateTime(calculator.startDateTime);
dueDate.addSeconds(1);
}
// if we have a schedule then check if the Due Date is in it and if it isn't
// find the next time we are in the schedule
if (calculator.schedule && !calculator.schedule.isInSchedule(dueDate))
dueDate.add(calculator.schedule.whenNext(dueDate, calculator.timezone));
// set the endDateTime property of the calculator object to dueDate
calculator.endDateTime = dueDate;
calculator.calcScheduleDuration();
})();
The example above includes defaulting Breach Time on the SLA to 1 second after the Start Time if the Due Date is empty or in the past.
If you created the example above with a name of Breach on Due Date then you would select this in an SLA Definition as shown below:
For more information on this topic see the SLA Landing Page
https://www.servicenow.com/community/itsm-articles/service-level-agreements-sla-faqs/ta-p/2313347