I am in the process of testing out xMatters as part of a trial, and one thing i'll need to do is handle logic & alerts concerning Priority of an Incident, as well as the time.
Example (using ServiceNow as the source system):
We want to use xMatters to engage our support staff for any Priority 1 or 2 incident, at any time of day. So.....if there's a P1 or P2 incident, that should always result in xMatters calling/contacting the appropriate support group, regardless of the time of day.
BUT
We also want to use xMatters to engage our support groups for Priority 3 or 4 incidents but only when they occur between 5pm and 8am.
So...summary:
P1 & P2: 24x7 Notification
P3 & P4: 5pm-8am Notification
Another complexity comes in when considering that a P3-4 incident may occur at 10pm, but then get resolved automatically before 8am...at which point we wouldn't want to notify anyone.
So.... thoughts? Ideas? I assume this would involve some shift-logic, and maybe altering the integration script to take this into account, but figured i'd ask here before going down any particular route. Has anyone else solved for this particular process/workflow before?
Comments
Please sign in to leave a comment.
Hi Nick, good questions here!
Have you considered on which end you want to look into this? Your ServiceNow admins could look at our scripts and see if there can be some added logic based on priority. That way ServiceNow can send only the requests that fit your requirements.
The other option would be to look at the Integration builder scripts that are on the xMatters web UI or server side. We can accept all the requests (per the original design) but then look at the priority and say go ahead and process a P1/P2 but do a time check before a P3/P4. This may get more complicated depending on timezones of the folks involved. When you say 5 PM to 8 AM is that in a particular timezone or can that vary? Would these rules only apply to certain groups or to all groups?
The easiest and likely simplest option here is to blast the horn whenever a P1/P2 occurs (i.e. when the ticket is created or updated to a P1/P2) but do nothing for a P3/P4. That part will be controlled by the Incident Alert feature. In the case of a P3/P4, you can use the Engage with xMatters form to send out a manual notification as needed so the teams can then be directed to only notify on those within your timeframe restrictions.
Are you concerned with user behavior and wanting to get in front of that so notifications are really only restricted to those times irrespective of whether or not someone uses the Engage feature?
So, quick answers first --
The Engage with xMatters option won't really work for this case, because it requires manual intervention. I need this to work automatically, without any human intervention/effort. We've already tested the Engage feature, and the Incident Alerts feature...so im familiar with those (they work great).
I assume the right approach will be to alter the Integration builder scripts, to include some timing logic, so i will likely go down that route. Im hoping someone has posted some code snippets in the Github community to reference :-)
The requirement really comes from our current business process for how support is handled. We really only intend on engaging folks via xMatters during non-business hours, AND for priority 1-2 incidents.
Totally makes sense Nick,
So if we are in agreement we are going to allow all of the incidents to send a notification request to xMatters but from there we need some logic to check whether or not it's a P3/P4 and if so whether or not we're in the timeframe to allow those to go through.
I did run across this:
https://stackoverflow.com/questions/26078488/how-to-check-if-current-time-falls-within-a-specific-range-considering-also-minu
which from a JavaScript perspective sounds pretty close to what you want to do for the time comparison between now and a particular date and time range.You can use this to create a calculation for after-hours to see if the time is within your desired interval.
You will want to put this calculation somewhere around line 28 of the Incident Alerts inbound script and then wrap the outcome of that in an IF statement to replace line 30 where the actual trigger fires off the event.
Line 30 should then become something like:
if((after-hours == true && (trigger.properties.priority == '3 - Medium' || trigger.properties.priority == '4 - Low')) || (trigger.properties.priority == '1 - Critical' || trigger.properties.priority == '2 - High'))
{
var response = form.post(trigger);
}
This is very high level at this point, and one of potentially a few ideas but I feel this could work with a bit of fine-tuning to your data coming back from ServiceNow and some trial and error.
If I have the time I can try this out on a local environment to see if something more detailed can be provided. If I did not expand enough on a particular step let me know!
This is great -- I'll see if i can kick the tires on this in our trial instance as well (and not break anything in the process :-)
I'll report back with results, hopefully in the next few days.
Turns out i had time today to figure it out.
Here's the changed code, replacing Line 29-30 with this block (which includes a commented out version of the original lines). Thanks for the help :-)
// NEW EDITED START
// P1 & P2 events should engage staff via xMatters 24x7
// P3 & P4 events should engage staff only between the specified non-business hour times.
// start and end times to denote when P3 & P4 events should use xMatters for notification
// this will cross the midnight boundary as intended.
var startTimeForP3P4Notifications = '5:00 PM' ;
var endTimeForP3P4Notifications = '8:00 AM' ;
var now = new Date();
var startDate = dateObj(startTimeForP3P4Notifications); // get date objects
var endDate = dateObj(endTimeForP3P4Notifications);
if (startDate > endDate) { // check if start comes before end
var temp = startDate; // if so, assume it's across midnight
startDate = endDate; // and swap the dates
endDate = temp;
}
var sendP3P4notifications = now < endDate && now > startDate ? false : true; // compare
function dateObj(d) { // date parser ...
var parts = d.split(/:|\s/),
date = new Date();
if (parts.pop().toLowerCase() == 'pm') parts[0] = (+parts[0]) + 12;
date.setHours(+parts.shift());
date.setMinutes(+parts.shift());
return date;
}
// must use the priority labels from ServiceNow
if((sendP3P4notifications === true && (trigger.properties.priority == '3 - Moderate' || trigger.properties.priority == '4 - Low')) || (trigger.properties.priority == '1 - Critical' || trigger.properties.priority == '2 - High')) {
var response = form.post(trigger);
console.log('CUSTOM MESSAGE: Success: Passed through custom script and posted trigger to form');
} else {
console.log('CUSTOM MESSAGE: Failed: Passed through custom script and did not post trigger to form');
}
// NEW EDITED END
// ORIGINAL START
// Create xMatters event
//var response = form.post(trigger);
// ORIGINAL END
Glad that worked out! Hopefully this can help anyone else who wants to do a bit of conditional work on their ServiceNow integration too.
Have a great weekend!
Last note before i forget ---- because I got stuck on this myself --- You have to go into the ServiceNow xMatters Configuration page, and tell the integration to send Incidents for Priority 1,2,3,4.
Out of the box, it only sends P1,2 ... but i forgot about that until a few confused tests were run and i realized the issue wasn't in the javascript. So...keep that in mind for anyone seeing this thread in future, to set it on the ServiceNow side too.
Fair point Nick!
Just to cross the i and dot the t on that, on the xMatters Configuration screen in ServiceNow you want to go to the Incident Notifications tab and make sure priority is set to 1,2,3,4 like you mentioned from the 1,2 which is default. Since you mentioned you were getting priority 1-4 already we looked over that part but for future reference yes that would be a precursor assumption to this solution.
Cheers!