SLA Breached

prabh · ‎07-10-2014

Hi All,

I have got the below requirement :

Create a custom field - "Breach Reason" in Incident table which should be mandatory while resolving a breached incident.

Please help.

Thanks & Regards,

Preety

sgrison · ‎07-10-2014

I am assuming you only have 1 SLA per incident.

Do you currently have a field to flag an incident table if it is breached? If not you can use the OOB esclation field which has the values (Normal, Moderate, High and Overdue). This field can be updated via your SLA workflow for each interval. For example when the workflow hits 50% you can put a run script in your workflow to update the escaltion field to 'Moderate'. The run script would look like this:

var id = current.task.sys_id;

var tsk = new GlideRecord('incident');

tsk.addQuery("sys_id", id);

tsk.query();

if (tsk.next()){

tsk.escalation = '1';

tsk.update();

}

Once this is in place then you can simply create a UI Policy to show and make mandatory the breach reason field when then escalation field is OVERDUE.

View solution in original post

Uncle Rob · ‎07-14-2014

If you ask me, the breach reasons should be part of the SLA record, with an interface built for teams to access those SLA's.

The reason I typically dislike SLA qualification on the Incident (or other task records) itself, is due to the fundamental 1 to many relationship. You can promise multiple things to a customer. You can even promise multiple things to other teams within the ticket's life cycle. SLA's are meant to track the promises, and are thus not a property of the parent record.

To illustrate. If you tell me of a service degradation, I promise you I'll get the ticket assigned to a person within 10 minutes. I'll further promise a status update in the first 30 minutes. I'll further promise to resolve the issue within 4 hours. 8 hours later, you finally find out the issue is resolved, and that's the first contact you've received.

In this example I've failed at least 2 of my 3 promises. What is THE failure reason?

sgrison · ‎07-14-2014

Absolutely agree. My proposed solution addresses a single SLA or 'promise' on the incident record. In the future if you start tracking multiple SLAs per incident then this approach will not meet the requirements. As Robert F mentioned the reason for breach could be tracked on the SLA record, there are a variety of ways to accomplish this but will depend on the specific details (# of SLAs, type of SLAs, etc).