Response SLA Definitions don't triggering due to conflicting Start and Stop conditions

[stephen_gannon]

SLA Resolution definitions are attaching correctly.

Question - Is there a better approach and if not how do I access the previous value of the incident's state field so that it is available in my second BR

SDA raises incidents in one of:

Acknowledged

Resolved

Resolved - Agreed with Customer

*Though   all options except open and closed need to be covered

The only way I can see from the limited info I have found is to create two   Before Business Rules.

1 - Allows Response SLA to trigger and attach

  Condition - State is not OPEN && updates = 0,

  Action - state is set to OPEN

  Order 900

2 - Restores previous state, completes SLA, Refreshes related list showing SLA and page with   original state

  Condition -   State is Open && Updates = 1

  Script to action above.......

  Order 950

  I am barely at beginner scripting level but the main sticking point (I think) is in the second BR I can't access the Incidents previous state ie Acknowledged/Resolved/etc so that I can use current.state=previous.state to dynamically restore the correct state to the ticket.  

  When hard coded using acknowledged and the condition builder, I noticed the updated state or the TASK SLA's related list was not reloaded even with 'action.setRedirectURL(current);'.

-------------------------------

Example of our P3 Response and Resolution SLAs, but effectively the stop condition on the response SLA "state is not OPEN" cancels out the condition when it is Acknowledged, Resolved etc.

Name - Priority 3 Resolution - 2 Bus. days

Start condition - Active = true .and. Priority = 3 - Moderate .and. Contact type != Alert .and. Caller VIP != true

Pause condition - State in (Suspend - Assigned to 3rd Party, Resolved, Resolved - Agreed with Customer, Sus...)

Stop condition - State = Closed

Reset condition - NONE

-----------------------------------

Name - Priority 3 Response - 4 hours

Start condition - Contact type != Alert .and. Priority = 3 - Moderate .and. Caller VIP != true .and. Active = true

Pause condition - NONE

Stop condition - State != Open

Reset condition - NONE

[larstange]

Hi Stephen

The reason why you second SLA (the 4 hour one) is not attached, is because your stop condition is met at creation time of the incident.

You can "cheat" the system by creating your own field which is set by an asynchronous business rule and then trigger you stop condition on this field in instead.

See Re: How to have SLA attched if already on creation you match the stop condition

[stephen_gannon · Accepted solution]

Hi Lars,

Thanks but this is not what I am after. The link you provided was really helpful though as it provided the clue I needed because it referenced this how to:

Modifying SLA Condition Rules - ServiceNow Wiki

and if there are no unintended consequences, it will be so simple.

The logic for cancelling the SLA attachment to an Incident, when the both the Stop and Start conditions are true is found in a script include - SLAConditionBase

// True if an instance of this SLA should be attached and started

  attach: function() {

  if (!this._conditionMatches(this.sla.start_condition))

  return false;

XX   //return (!this.complete()); // don't start, if completion (stop) condition is also true

YY   return true; //Starts SLA and then triggers STOP condition

I replaced YY for XX and on initial testing, it works perfectly.

Regards

[larstange]

Hi Stephen

You have fixed the problem at its root instead of working around it.

But just remember that you have now modified a central part of the SLA module, so from here on out you will have to monitor for skipped changes to this script include everytime you patch or upgrade. So your approach comes with a price.

[stephen_gannon]

Thanks Lars.

Yes more Admin overhead and this fix would need to go to CAB as it is a global modification that might impact future domain separated customers requirements (or our ability to deliver them).

I am double checking the validity of the problem I am trying to solve, which is the Reporting Team needing the SLA's on the Incidents to run reports on. Moving to ServiceNow may be a good chance to explore new metrics or to   re-jig reporting and leave the base system files alone, so I have opened the discussions with reporting and the SDMs.

Regards

Steve