Incident Response SLA

Don Tanner · ‎01-31-2017

I would like to create a Response SLA on Incident based on the Assigned to updating the incident. The SLA is not started until Assigned_to is populated. There is an Assignment SLA as assignment will be handled by a group. I tried to stop the SLA when Updated By is same as Assigned_to.name (It would not allow me to select just Assigned_to). This failed so I checked History on the Incident and it appears that Updated By is not populated. Any advice would be greatly appreciated.

edwajs · ‎01-31-2017

Hi Don,

Creating a Response SLA is a common requirement, and you can find some relevant posts by searching the community. But I want to answer some of your questions and provide some suggestions for how to implement this SLA Definition.

I suspect your Stop Condition is not working because the Updated by field (sys_updated_by) is populated with the User ID (user_name field in the sys_user table) by default. It is not populated with the contents of sys_user name field, which is what you are dot-walking. And Assigned to is a reference field, so if you were trying to compare it to another field, the Condition Builder may not permit it for certain combinations, which is probably what you encountered.

The Updated by (sys_updated_by) field is a system field, so it is not audited, which is why you can't see it in as a separate entry in the sys_audit table. For any given audited update, however, it is the sys_created_by value for the sys_audit records.

My suggestion for creating a simple Response SLA is:

Add a custom true/false field, Responded to (u_responded_to), to your Incident table. You will initialize this field as false, and you will not put it on the form.
Decide what your criteria is for setting this field to true, and design and implement a before-insert-update business rule to evaluate the criteria and set the field to true when it is met.
1. EXAMPLE: Your criteria is met when the person updating the incident is the assigned_to person, and they are making a customer-visible update. You can do this with a simple script in your business rule where you check !current.assigned_to.nil() && current.comments.changes() && current.assigned_to == gs.getUserID(), and if this is all true (Assigned to is not empty, and there are customer-visible comments, and the person making the update is the Assigned to person), the you set the u_responded_to field to true.
Now define your Response SLA:
1. Start condition: Active is true and Assigned to is not empty
2. Stop condition: Responded to is true

Here is a description of how the above Response SLA will behave:

It will create a Response SLA record for the Incident, and it will be In Progress when the Assigned to field is populated in the Incident.
The Response SLA will be Completed as soon as the Assigned to makes a customer-visible update.
If the Assigned to is emptied out before it has been responded to, that Response SLA will be Cancelled.
A second Response SLA will be started if the Assigned to is filled back in. It will be Completed as soon as the Assigned to makes a customer-visible update.
If the Incident is Closed and is no longer active, the Response SLA will be cancelled.
If the Incident is taken on by a person (i.e., they have populated themselves into Assigned to field) and they provide a customer-visible update at the same time, both the Start and Stop conditions will be true and with default SLA Condition processing, you will not get any Response SLA generated (it would be measuring zero duration, and base SLA condition processing will not create a record).
As soon as the criteria is met for the Responded to field, any active Response SLA records (there should only be one at any time) will be marked Completed, and no additional Response SLA records will be created (the Stop condition is true).

For more information about SLA Conditions, you can check out this knowledge article.

For more general information Service Level Agreements, there is also this excellent FAQ.

Good luck with your Response SLA implementation, and if you find this response helpful, give it a like.

Ed Wajs

Technical Support Developer

View solution in original post

montanadawgz · ‎01-22-2019

Thanks

I applied the recommendation by creating the Responded_to as a true false field to Incident. Default set to false

I added the Business Rule and conditions before, and the conditions to change it to true.

I added the field to appear on the Incident form to test to make sure it's working.

I created a new record in the SLA Definition table:

Type: SLA

Target: Response

Table: Incident

Workflow: Default SLA workflow

Duration: 2 hours

Schedule Source: SLA Defintion

Schedule: 8-5 weekdays

Start Conditions:

Active is true

Assigned to is not empty

Priority is not empty

*Set start to Created

Stop Conditions:

Responded_to is true.

Now I want to report the time in the SLA time for the Responded_to Stop.