Service Level Agreements (SLA) FAQs

[Nigel Bell]

Service Level Agreements (SLA) — FAQs

Questions addressed in this document

1.   Why is my SLA not getting attached to the Task record?

• • Check for "Active" flag on the SLA Definition

              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.

• • Check the "Start condition" on the SLA Definition

                          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.

             

• • Check the "Stop condition" and "Cancel condition" on 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 customized Business Rules that might be setting workflow to false

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 are active

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

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?

• • Check if SLA Engine is set to run asynchronously

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?

• • Check the "Start condition" on the SLA Definition

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: has been selected on the SLA Definition then in addition to the above: Cancel condition does not match	Start condition matches Note: for Helsinki or later instances, the new Cancel condition cannot be used with the Simple SLA Condition Rule
An SLA will stop (complete) when...	Stop condition matches	Stop condition matches
An SLA will reattach (reset) when...	Reset condition matches Start condition matches	Reset 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 Never No conditions checked as SLA cannot cancel Cancel conditions are met Cancel condition matches	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...	Pause condition matches For Helsinki or later instances, if: has been selected on the SLA Definition then in addition to the above: Resume condition does not match	Pause condition matches Note: for Helsinki or later instances, the new Resume condition cannot be used with the Simple SLA Condition Rule
An SLA will resume when...	Pause condition does not match For Helsinki or later instances, if: has been selected on the SLA Definition then in addition to the above: Resume condition matches	Pause condition does not match Note: for Helsinki or later instances, the new Resume condition cannot be used with the Simple SLA Condition Rule

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

[The SN Nerd]

I've noticed that this doesn't properly incorporate schedule.

For example, if expected delivery is 2 business days, and the SLA starts on Friday at 1PM, it thinks that the SLA expires on 8:00 AM on Monday (start of the business day).

The expected expiry time is Tuesday 1PM.

Has anyone codified this?

[soumyamitra]

Hi Paul,

Is your comment in relation to point #10? In the script used in #10 if the field 'due_date' has a value out of schedule, the next valid time in the schedule is picked up.

If your requirement is to have a relative duration calculated which ends in 2 business days, the below line should do:

calculator.calcRelativeDueDate(calculator.startDateTime, 2);

For more examples pls see - Define a relative duration

If you are looking for something else, please add in more details and we can respond appropriately.

Thanks

Soumya

[utente]

Hi,

My congratulations for the beautiful document, it's very useful   🙂

I have one question:

If I use the script indicated, at the point #10 (Breach time by DueDate)

I have seen that the SLA related to the ticket don't change the field "Breach time" [ planned_end_time ] (indicated on the SLA, next to the field "start Time" [start_time])

(indicated in the SLA, next to the field "start Time" [start_time])

I have tried ti add to the script, the following line:

calculator.planned_end_time = dueDate;

but the result doesn't change, the filed conserve the fist date calculated.

who is possible to make an update also to this field?

Thanks,

Vincenzo

[Nigel Bell]

Hi Vincenzo,

Pleased that you've found this doc useful.

Regarding your question - is the scenario you're asking about:

• create a ticket with a date/time in the "Due date" field
• SLA gets attached to the ticket with the "Breach time" ("planned_end_time") set to the "Due date"
• "Due date" field is modified on the ticket
• Already attached SLA keeps the same "Breach time"

If you can confirm I've understood what you're asking correctly I can provide some information around this and possible approach for solving it.

If I've misunderstood could you explain again and I'll try and help.

Regards,

Nigel

P.S.   the "calculator" object used in the script field of Relative Duration records is an instance of the "DurationCalculator" script include.   The SLA engine runs the script defined n the relative duration and uses the "endDateTime" property of the "calculator" object to set the "planned_end_time" on the SLA.   So the extra line you added of "calculator.planned_end_time = dueDate" would not have had any affect.

[utente]

Hi Nigel,

Yes, I confirm that my target is to change the Breach time in the SLA already attached.

After your last indication,  

I'm thinking that the correct route is to modify the Script related to the field "relative duration", right?

Best Regards,

Vincenzo

[Nigel Bell]

Hi Vincenzo,

I'm sorry for the delay in getting back to you.

For SLA Definitions that use a Relative Duration, the Breach time ("planned_end_time") field on a Task SLA is only calculated at the point it is attached to the Task so changing the script field in the relative duration will not help with the re-calculation you need.

I think I know what you want to do - whenever the "Due date" is changed you want the "Breach time" on the Task SLA record to be updated to match it...is that correct?

This can be achieved but will need a bit more configuration...

Have you used the "Reset condition" on SLA Definitions?

When a Task matches both the reset and start conditions on an SLA Definition the currently active Task SLA will be marked as completed and a new Task SLA attached (which would also result in a the "Breach time" being re-calculated).   So now we just need to find a way to know when the "Due date" has changed so we can use the reset condition.

Unfortunately, you cannot define conditions on an SLA Definition to match when a field has changed but we can work around this.

The steps would be:

1. Create a custom string field on the Task table which will be used to store the names of all fields that have changed when a Task record is updated.
   This field should be extra large and for this example we'll call it "Changed fields" (column name will be "u_changed_fields"):
   
   This field does not need to be shown on any forms - it just needs to exist.
   
   
2. Create a business rule to populate "Changed fields" with the names of any fields that have changed whenever a Task is updated.
   The 2 screenshots show an example of a business rule that can be used to do this:
   
   The script shown in the screenshot below is:
   
       (function executeRule(current, previous /*null when async*/) {
   
             current.u_changed_fields = "!" + j2js(GlideScriptRecordUtil.get(current).getChangedFieldNames()).join("!") + "!";
   
         })(current, previous);
   
   
   With this business rule in place, if for example you update the "Short description", "Priority" and "Due date" fields on an Incident, the new "Changed fields" ["u_changed_fields"] field would contain:
   
           !short_description!priority!due_date!
   
   This now means we can use the contents of this field to know if the "Due date" field has changed
   
   
3. Update your SLA Definition to have a reset condition that tests for the "Changed fields" field containing "!due_date!" - example is shown in the screenshot below:
   
   
   

With this configuration, when the "Due date" changes the existing Task SLA will be set to "Completed" made inactive and a new Task SLA will be created with a "Breach time" that matches the updated value for "Due date".

I hope that all makes sense!

Let me know if you have any questions on this.

Regards,

Nigel

[utente]

Hi Nigel,

Very thank you for your help.

This solution is very interesting  

My best regards,

Vincenzo

[kiranbahl27]

Hi is there a way to see like a red color in the task list view if it has been breached

[knight202]

Hi Nigel,

Is there a way to have the SLA cancel instead of reset and fire a new SLA? I'd like to be able to factor-out the canceled SLAs when reporting at the end of the reporting period. Please let me know if you need more clarification. Thanks in advance. Best, Jason

[mownika]

Hi,

How can I define an SLA that has condition initial due date must be 0 hours before revised due date in problem(ptask). I am not able to find whether it has breached or not.

[Deepthi25]

Hi Team,

Can i know where is the script written for this stage written on hr_case

[GordonBanks]

Hi Radhi,

What are you trying to understand here, as the processing of SLA's is done by the TaskSLAController regardless of whether the SLA is associated to HR or any other task record defined with a SLA definition.

Depending on the SLA definition ( in this case HR SLA Poland 15 Days) can be cancelled when the cancel condition is met.

[GianLuca Giusti]

SLA elapsed time measures

Troubleshooting service level agreements (SLAs)

Understanding SLA Conditions

Configure Service Level Agreement (SLA) properties

Service Contract SLAs do not attach after New York upgrade

[Sagar_pawar]

Hello @Nigel Bell ,

on sla definition form, there is a schedule filed in that there is one option 8-5 weekdays.

what is the meaning of 8 to 5 weekdays .please guide me on this

Thank You.