Awaiting User Info - Inactivity Monitor and Email trigger - Not Working

marcink · ‎01-29-2020

Hi all.

I am trying to setup an inactivity monitor for incidents that are in Awaiting USer info for lnger than a day and then trigger notification emails to be send to the caller each day untill they provide an update.

I have searched this forums and tried applying what i found to no avail, see below what i setup - could anyone point me in the right direction of what am I missing ?

Inactivity Monitor:

Email Notifications:

Business Rule:

I have only set the When to Run, but i cannot figure out what to put in actions tab as I only have below available:

In Scheduled Jobs i can see activity monitor Running and after checking some it looks for state "awaiting user info" but includes other teams not Business Inteligence as requested. But i cannot see any emails being fired. Not sure what it does at this point other than checking ?

I also required that this System update prompt is added onto the incident for visibility.

Any pointers will be welcome - please dont send me to Wiki as i have gone through this:

https://community.servicenow.com/community?id=community_blog&sys_id=956daa29dbd0dbc01dcaf3231f9619cb

https://docs.servicenow.com/bundle/jakarta-platform-administration/page/administer/time/task/t_SetAn...

https://community.servicenow.com/community?id=community_question&sys_id=62e603e5db1cdbc01dcaf3231f96...

This last one i followed with exception to auto resolving and this still won't do it ?;/

Thanks in advance.

johnfeist · ‎01-29-2020

Hi marcink,

I have a similar situation and resolved it via a different approach. Let's take the basic case that once a day you will send a dunning notice to the assignee on any incident that hasn't been updated in a day or more.

I don't use any BRs. Rather I use a script like this:

sendNotice : function() {
    var rightNow = new GlideDateTime();
    rightNow.addDaysLocalTime(-1);  //you may want to use UTC time, check the documentation
    var theGroup = new GlideRecord("sys_user_group");
    theGroup.get("name","Business Intelligence");
    var theIncidents = new GlideRecord("incident");
    theIncidents.addQuery("sys_updated_on", "<", rightNow);
    theIncidents.addQuery("state", 3); //on hold
    theIncidents.addQuery("hold_reason", 1); //This is awaiting caller
    theIncidents.addQuery("assignment_group"," theGroup.sys_id); 
    theIncidents.query();
    var incidentCount = theIncidents.getRowCount(); //this isn't necessary but useful when debugging
    while (theIncidents.next()){
	gs.eventQueue("<notification name>", theIncidents, theIncidents.number, theIncidents.assigned_to);
    }
},

I may have done a little fat fingering when setting up the above, but the code works for me. You can check in the dictionary for On Hold reason for the correct reason.

Have your notification set up to be triggered by whatever event you define and assign the two params as needed.

When you set up your job all you need is the following in run this script

var zot = new <your script name>();
zot.<your function name>();

To post a notice (addErrorMessage() to put it in red), you can put a script in a UI policy or an load client script based on the logic in the function.

Hope that helps.

:{)

Helpful and Correct tags are appreciated and help others to find information faster

View solution in original post

marcink · ‎01-29-2020

Hi Ian - I have little(to none!) scripting skills (still learning), would you be able to share your workflow design ?

Thanks.

Ian Mildon · ‎01-29-2020

Sure. The trigger conditions on the Workflow are:

State is On Hold
On hold reason is Awaiting Caller

Then the workflow itself looks like this.

Additionally I have the Workflow running against a preset Schedule and the timers are set to be 18hrs and 9hrs respectively (2 actual business day hours and 1 actual business day hours).

This is also dependent on the "reset" provided by an OOB Business Rule called "Incident State Change to In Progress", which I modified with a script to delete the current workflow; so the entire process could be re-used on the same Incident, if needed at a later date.