Customers working with Service Level Agreements may encounter the legacy SLA fields. Then they may have more questions about these fields or want to use them.
Part of the documentation states:
Previously, only a single SLA could be attached to a task via the Escalation engine. The information for the SLA was stored in the task table using the SLA Due, Made SLA, and Escalation fields.
The Task SLA engine now enables multiple SLAs to be attached to a single task, making the earlier task fields redundant. Their equivalents are in the task_sla table for each SLA attached to the task.
- Task SLA, Breach time: This is equivalent to the SLA Due field
- Task SLA, Has breached: This will be true if the SLA has breached, the opposite of Made SLA field.
- There is no equivalent field for Escalation field. Notifications can be sent via the SLA workflow and an increase in priority can trigger additional SLAs to be attached to the task.
The fields on the Task are considered legacy and are not updated by the Task SLA engine. In case these fields are being updated, the legacy Escalation Engine may still be running. This can happen if you have upgraded from Express or a previous version.
We also provide additional information and guidance about these legacy SLA fields:
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. Because the values may change unexpectedly, they are not intended for customer use.At this point, you may be thinking "Golly! When I was doing research on the Community to try to figure out how to meet the latest demand...um...request from my users, I found a nifty solution, but it uses the legacy SLA Due field. How am I going to implement it now?" If you search the Community for "SLA Due" you will find a number of posts with suggestions and sample code. In the following sections I am going to explore several questions from the Community, and suggest some ways to get the desired features.
How do I provide information at the top of my task form for the next SLA breach?
A common recommendation in Community posts is to populate the SLA Due field with a Breach time from a Task SLA. The SLA Due field is put at the top of the form layout so the person working on the Task can see how much time they have until their next SLA is going to breach.
This is undesirable for several reasons:
- Per guidance from Development, some of these legacy fields may get changed unexpectedly and you can get the wrong time.
- The method for doing this is typically an after-update business rule on Task SLA which posts the desired value back into the record.
- At a minimum you must turn off auditing for this update to prevent recursion.
- There can be multiple Task SLA records associated to the same Task and you have to make sure you are selecting the correct value.
If you can't use the SLA Due field to display a Breach time, what are some other ways of putting that information at the top of the form?
Option 1: Put your Task SLA information as an embedded list at the top of the form
The default layout for an incident, with the Task SLA information as a related list at the bottom of the form, requires scrolling to get to this information.
Use Configure > Form Layout to make this an embedded list at the top of the form. Be sure to add the 'begin split' element below the embedded list so it spans the top of the form! If the 'begin split' is missing, the embedded list is squeezed into the top left half of the form and messes up the rest of the layout.
With this simple configuration change, the desired information is now at the top of the form - just like magic!
Option 2: Use a before-display business rule to write the desired Task SLA information as messages at the top of the form.
You might belong to an organization that attaches forty-five or fifty active Task SLA records to every incident (and you have my deepest sympathies). For this case, you won't want to put a list of all Task SLA records at the top of the form because you will have to scroll to do any work. But you can put a before-display business rule in place with a simple query to fetch the information and post it as a message. Each time the form reloads the message will be displayed at the top.
Here is a sample before-display business rule with order 200 based on the Calc SLAs on Display business rule. Note that we only care about Active Task SLA records which are not Paused, because the Breach time doesn't have any meaning while Paused and will be recalculated when it changes to a different Stage.
Here is the resulting message from the business rule:
This method is suitable for a variety of different messages you can post, based on the query and the resulting message you wish to construct. For instance, if the SLA is already breached you may not want a message so you can filter it out.
How do I report on my SLAs? -- AND -- How do I get a list of my Tasks ordered by the Breach time?
These are the same requirement because a list view is just another report. People make a mistake of generating inaccurate reports if they decide to rely on the legacy Escalation Engine fields. Remember, those fields only support a single SLA per task and you can have multiple Task SLA records for a task. Do your reporting or use a list view against the Task SLA table or one of the provided database views joining specific Task Types with the Task SLA table.
Here are some of the provided database views joining different tables extended off task together with the task_sla table:
How do I get a specific Breach time into an Incident email?
There is an issue with this requirement even if you are posting information back from the Task SLA record into the SLA Due field. The Task SLA records need to exist before the associated notification or event for the email are triggered. This means the 'Run SLAs' business rule (after-insert-update business rule on the task table, order 101) has to run first. If you are relying on an event generated by the 'incident events' business rule (after-insert-update business rule on the incident table, order 50) it might only produce the expected mail intermittently, if at all. Event processing is asynchronous and it has to happen after the SLA Engine has finished its work.
Once you ensure your Notification runs only after the data exists, use a mail script to query the Task SLA records and get the desired Breach time value.
Suggestion:
One easy way to ensure your Notification runs after the data exists is by creating the notification with with an after-insert-update business rule on the incident table, order 102.
----
In conclusion, if you do a quick search of the Community for posts about SLA Due, you find a number of posts with tips or sample code to populate this legacy field. ServiceNow Development discourages the posting back of information from a Task SLA record back to the associated Task record, especially if it is posted back to the legacy Escalation Engine fields.
This blog discusses several common business requirements from the Community and alternative methods for achieving them without using the legacy Escalation Engine fields.
Here are some of the community posts referenced in creating this blog:
- How do I set the SLA Due field to be the same as the Breach Time?
- Incident SLA Due > UNKNOWN value which contains Custom Business Rule for SLA Due Field
- SLA field value not updating when task sla changes
- Getting SLA Due (sla_due) to update with lesser SLA date
- Possible to change the value captured in Incident sla_due field with multiple SLA's attached?
2 Comments
