Hello,
I've been exploring the ServiceNow & xMatters integration and wanted to know if the below scenario is possible (dealing with just incidents).
My understanding is that the xMatters Plugin in ServiceNow uses the hardcoded URI for the inbound HTTP trigger in xMatters to initiate the corresponding Flow, that flow is tied to a Form (which handles the messages and responses).
ServiceNow Incident BR -> Flow HTTP Trigger -> Form
The Scenario: When an incident gets created, based on the company and priority of the incident, a different group gets notified and how they get notified.
Company A - P1 only - phone call - Group A
Company A - Everything else - SMS/Email - Group AA
Company B - P1 to P3 - Phone/SMS/Email - Group B
Company C - SMS only - Group C
Is this possible? The inbound package will always stay the same, it's just the data will be different and will determine what happens next.
Thanks.
Comments
Please sign in to leave a comment.
Hey Ryan!
You're pretty close, except the out of box ServiceNow integration uses the older Integration Builder, which is the underpinnings of the Flow Designer. This just means that instead of nice steps you make all your logic in the javascript code in the Inbound Script. If you want to see the nitty gritty details, check the diagrams on this page.
Anyway, on the integration builder tab in xMatters, you'll see the inbound integrations. Open up the one that says "incident alerts" (and click the Edit Script button). This is where you'll add your logic. The scripts on the ServiceNow side will iterate through all the fields in the incident record and include them in the payload sent to the integration builder. This entire model is available in the "trigger.properties" object. So, assuming the Company A value is stored in the "company" (or is it "domain"?) field of the incident record, then you'd access this value as "trigger.properties.company". This means you can make if blocks based on this value.
The second piece you'll need is the syntax for targeting the devices. The "trigger" payload syntax is defined in the docs here. You'll need to target the devices by name rather than type, so it will be "SMS Phone", "Work Email", etc. These are all visible in the Admin > Device Types section (or in the Devices section under your profile).
Putting it all together, one block might be:
if( trigger.properties.company == "Company A" ) {if( trigger.properties.priority == "1" ) {
trigger.targetDeviceNames = [ { "name": "Work Phone" }, { "name": "Mobile Phone"} ];
trigger.recipients = [ {"id": "Group A" } ];
}
else {
trigger.targetDeviceNames = [ { "name": "SMS Phone" }, { "name": "Work Email"} ];
trigger.recipients = [ {"id": "Group AA" } ];
}
}
You will need to read through the script a bit as it will try to set the "trigger.recipients" to the assignment group, but if you add your company logic after that section, you will override when the conditions match.
I hope that helps! Let us know if you have other questions.
P.S. I'm guessing you're running a multi-tenant ServiceNow instance? You'll need to make sure your business rules properly trigger. I'm not immediately familiar on how to do this, but post back if you have trouble here.
Thanks Travis that was really helpful,
1. Correct, the company field on the incoming incident payload will contain the information I need.
2. We are multi-tenant but the oob business rule runs in the global domain for all incidents, so all good there.
It looks like there's two ways of doing this?
If I understand your post, If I go based on the OOB SNOW Integration builder, I would modify the Transformation Script in the integration builder to point it to the forms I want based on the previous conditions mentioned which I can test through the data in the payload.
Or
Do it all through a new Workflow - Leverage Flow Designer (which I just realized creates your integration builder script).
Either way, is their a diagram or documentation that you can point me to that shows the relationships of the xMatter Objects at a high level? Triggers, Events, Forms? Anything else I should read up on?
> Do it all through a new Workflow - Leverage Flow Designer (which I just realized creates your integration builder script).
Two points here. I think what you might be seeing is the existing IB script which will run in series with the flow designer steps. Which makes it nice for adding additional logic and notification streams to the existing IB process, but will not supplant or be generated by the flow designer.
So, normally I would be fully supportive of this action, except there are several nuances of the ServiceNow integration that collide with a couple of missing features of the flow designer. Namely, the response options. There are a handful of UUIDs that are added to the config screen of the xMatters plugin that determine which response options to display to the users. ("Accept" for targeting a single user, "Assign to me" when targeting a group.) You can get around this by creating a new form with different response options.
Also, you'd have to dig out the code to report back to ServiceNow that the event was created, which is the chunk of code at the end of the current Incident Alert inbound integration script. This code would need to be added to a custom step.
Whew... what a novel. Maybe somewhere in there is some answers. But as always, if you have more questions, don't hesitate to post!
Thanks for this, gonna chew on this and get my understanding on forms better and will definitely reach out if I have questions.
Thanks again.
No problem Ryan, we'll be keeping an eye out on this thread so if you have more questions just let us know.
Happy Tuesday!