Stop SLA when additional comment entered

[Chris77]

Hey folks, 

So I have been working on creating an SLA for a specified group that closes out when a user enters an additional comment on the work notes. I am not allowed to create new fields on the incident table (so creating a true/false field then having a business rule trigger it is out of the question). I created a script include that extends slaconditionbase and created a new SLA condition to reference that script. I am able to add some script to have the sla complete when additional comments are entered. Now the only problem is once the sla completes (because a comment was entered) It keeps reattaching once they assign it to a different user in the group. I need the incident to just complete and not reattach unless the incident leaves the group and then comes back to the group. I have adding some script in the script includes basically telling it not to attach if the sla has already completed. However, it seems this is not working. Any help would be appreciated. I also tried adding script to just have it leave the script include once the complete function returns true. However, as soon as the incident gets reassigned or gets unassigned (but stays in the group) it will reattach. Thank you all for your time.

[Chris77 · Accepted solution]

Thanks again for all the responses. I was able to figure it out finally. I went ahead and created a new script include that extends the SLAConditionBase class. I then created a new SLAConditionType that referenced that Script Include and just added some script to the attach: function() and the complete: function(). The documentation that led me to go about this route is located at  https://docs.servicenow.com/bundle/madrid-it-service-management/page/product/service-level-managemen... (in the event someone in the future has the same task they are trying to complete. Thanks again for everyone's input.

[Jon G1]

Hi Chris,

I have a very similar need to attach an SLA and stop it once a comment is entered without ever reattaching to the same task.  Can you elaborate at all on the script conditions you used in the custom SLA Condition Rule you created?

[Chris77]

I believe we put that logic in the simple condition builder to prevent it from re attaching. We only scripted the attach and complete function. Everything else was done through the condition builder (not scripted). The script we created just to check that the user who left the comment was in the group that we are targeting. In the script we basically said  in the complete function. if(this._conditionMatches(this.sla.stop.condition) || gs.getUser().isMemberOf(your group() && current.work_notes.changes() || etc... From here basically you can customize it to fit your needs. But this  conditionmatches the sla stop condition allows the script to work with the simple condition builder. As far as only attaching once you can set a boolean variable to true in the script and once you hit your end condition trigger that to false and add that in the

attach: function() {

if(!this._conditionMatches(this.sla.start_condition) && myBooleanValue == 'false')

  return false;

}},

[Jon G1]

Thanks for the tip Chris.  That's helpful.

I spent some time over the weekend and I was able to figure this out on my own.  Your solution sounds simpler than mine but perhaps my conditions are a little bit different as I don't think a boolean as you suggested would fit my case.  The boolean wouldn't persist from one instance of the SLA to the next, and the active conditions are met more than once.  I've seen some people suggest a "pause" trick to avoid attaching the same SLA multiple times (pause once the condition is met, prevent all reset conditions, and only complete the SLA once the ticket is closed).

In my case, the SLA attaches as it should based on the SLA Start Conditions.  And it completes in a similar case to yours - when a comment is added.

The problem that I was having was that a new instance of the SLA would attach again since the start conditions were met again after the previous SLA completed.  We only want this SLA to run once ever on a task.

I ended up creating a gliderecord lookup that checks whether the task already had an SLA with this definition attached.

My reattach always returns false - from what I can tell, that's triggered based on the Reset condition, but I never want this SLA to reset.

My attach condition looks like this: 

    attach: function () {
        if (!this._conditionMatches(this.sla.start_condition) || this._attachedPreviously()) {
            return false;
        }
        return (!this.complete() && !this.cancel()); // we should start - but don't start, if completion (stop) or cancel condition is also true
    },

And that _attachedPreviously function looks like this:

    _attachedPreviously: function () {
        var timeToFirstResponse = '9a8f8b651befbc1073fa400abc4bcb02';
        var slaLookup = new GlideRecord('task_sla');
        slaLookup.addQuery('task', this.task.sys_id);
        slaLookup.addQuery('sla.condition_class', timeToFirstResponse);
        slaLookup.query();
        return (slaLookup.getRowCount() > 0);
    }

I'm going to see what I can do about getting rid of that hard coding, but this seems to be working now.

My complete condition checks that comments have changed and that the person making the change is an internal employee - we don't want this to complete when an external user responds.  It looks like this:  

complete: function () {
        var commentsChanged = 'commentsVALCHANGES^EQ';
        var myCompany = gs.getProperty('myCompany.company.sys_id'); //custom to my instance - update or adjust as appropriate
        var currentUser = gs.getUser().getRecord();

        //check if comments have changed
        //check if user adding comment is an internal employee
        if (this._conditionMatches(commentsChanged) && currentUser.getValue('company') == myCompany) {
            return true;
        }
        return false;
    },

I appreciate your response - hopefully this will help someone in the future who has similar needs.