From SNCWiki

Functionality described here requires the SLA plugin.

Functionality described here requires the Admin role.

Note: Ensure that the old SLA engine isn't running at the same time as this new engine. You may need to remove all the entries in the SLA Management table to fully disable it.

Overview

The SLA Plugin is a greatly enhanced version of the out-of-box SLA engine. Tasks can now run multiple SLAs simultaneously, the escalation concept has been replaced with the more robust Workflow Engine, and reporting has significantly improved. To start using this SLA engine, activate the SLA plugin.

For information on implementing the plugin on instances that have been using the out-of-box SLA engine, see Getting Started with the SLA Plugin.

The SLA plugin uses the tables contract_sla and task_sla, as opposed to the out-of-box SLA engine, which uses the table sysrule_escalate. For information on using the out-of-box SLA engine, see Service Level Agreements.

Using the SLA Plugin

Video Demo (11 minutes)

Here is a short video showcasing the functionality described below:

Example

SLA field definitions 

• Name - The name of the SLA. This is only for human reference purposes.
• Type - Choose SLA, OLA, or Underpinning contract. This is strictly for human reference and reporting purposes.
• Duration - Dictates how long this SLA will measure before constituting a 'Breach'. A Relative Duration can be specified.
• Table - The table that houses the records the SLA will be running against. Typically this is incident, problem, or change.
• Workflow (optional) - The workflow that will run against this SLA. SLA workflows generally contain escalation schedules and notifications. NOTE: Workflows associated to the task_sla table have to have their If condition matches field set to None. If it is set to something else, you may notice that the workflow will be fired twice for each SLA.
  
• Retroactive - Ensures that when this SLA is started, its 'start time' will be set to another specified value (like the incident's 'Created' time, as opposed to now).
• Set start to - Specifies the field in the incident where we can go get the retroactive start time. This is generally the incident's 'Created' field.

• Start condition - Specifies when this SLA should be pulled into the incident. This field is (re)checked every time an incident is updated.
• Pause condition - Specifies when this SLA should be paused. The SLA will resume when the pause condition is no longer valid. This field is (re)checked every time an incident is updated.
• Stop condition - Specifies when this SLA has fulfilled its measurement criteria, and when the SLA should be marked as either Achieved, or Breached.

Note: Although you can personalize the form to add a Reset Condition, the Reset Condition feature does not work.

Periodic field updates

Every 2 minutes (configurable), a scheduled job (running in the background) will re-calculate the six time-based fields on all active, non-paused SLAs. While these re-calculations are not necessary for the SLA plugin to function, the background job is designed to give your users a 'recently up to date' view of what SLAs are closest to breaching, as well as giving them the ability to sort their SLA lists to have the 'most pressing' work bubble up to the top. This calculation is also run one final time when an SLA is stopped/cancelled, to ensure that the numbers are accurate to within seconds (for later reporting).

The six time-based fields are:

• Actual Elapsed Time - Time between start time and now (minus pause duration).
  
• Actual Elapsed Percentage - Percentage of total SLA that has elapsed (minus pause duration).
  
• Actual Time Left - Time remaining until SLA breach.
  
• Business Elapsed Time - Time within the specified schedule between start time and now (minus pause duration).
  
• Business Elapsed Percentage - Percentage of total SLA that has elapsed within the specified schedule (minus pause duration).
  
• Business Time Left - Time within the schedule remaining until SLA breach.
  

Legacy Calendars and Service Level Management

Note: Legacy Calendars (System Scheduler --> Calendars) do not apply to the new Service Level Management --> SLA's. But you can set up a schedule so that the SLA Duration will only be applied to the scheduled days and times.

FAQ

Q:"It's Saturday, why is my SLA still counting?"

A: I open an Incident with an 8 hour SLA on Friday at Noon with a schedule of M-F 8-5. This would put the planned end time Monday at 11am (five hours will expire on Friday and the remaing three would run on Monday morning). But because the time left field shows actual time left (independent of business hours), it will set itself to 71 hours (Friday at Noon to Monday at 11am) and begin counting down (even through the weekend).

Q: "In the duration field, does 1 'day' mean 24 hours or 1 business day?"

A: The duration field only deals in real time, meaning that typing '1' into the 'day' field is the same as typing '24' into the 'hour' field. This is before the schedule is applied, so 1 day in the duration field is 3 business days after the schedule is applied.

Q: "Why am I getting a 'Error running business rule: Pause SLA, exception: java.lang.NumberFormatException' error when an SLA pauses?"

 
var dic = new GlideRecord("sys_dictionary");
dic.addQuery("name", 'task_sla'); 
dic.addQuery("element", 'pause_time'); 
dic.addQuery("internal_type", 'glide_duration'); 
dic.query(); 
if (dic.next()) { 
  dic.internal_type = 'glide_date_time';
  dic.update(); 
}

A: You can add the following mail script to your email notifications to get the link to the incident:

<mail_script>
template.print("SLA warning for: ");
template.print('<a href="https://INSTANCENAME.service-now.com/incident.do?sys_id=' + 
  current.task.sys_id + '">' + '${task.number}' + '</a>\n');
</mail_script>

Q: "Can I still use the old 'SLA Due' field (used by the old SLA engine)?"

var tsk = new GlideRecord('task');
tsk.get(current.task);
tsk.sla_due = current.planned_end_time;
tsk.update();