Forwarding. The new reassigning.

Hey guys! Kevin here with more great tips on using xMatters. 

Have you ever gotten an alert from xMatters and realized it needs to go to someone else? Or maybe you wanted to share the alert with your teammate for further investigating in the morning? In this article we'll build a forwarding workflow using the Events Comments trigger. 


Here's a peek of what we'll be building:


Our flow is kicked off from the Event Comments trigger. That's this guy here:



Check out the docs for the Event Comments trigger here


He fires when someone adds a comment after selecting any response from an xMatters notification. We'll hook him up to our friend the switch step:


Note that we're switching paths based on the Comments.annotation.response.response property coming out of the event comments trigger. I want my flow to only fire when someone responds with "Forward" and they have entered comments, so we need a step to go get the group. Let's call it Get a Group step. For clarity, I've moved the script and input/output listing to the end of the article, go here to get the goods. 


This step makes a call into the GET /groups/{groupId} API call to get a single group with the given ID or name. We pass in the annotation.comment property from the Event Comment trigger:


The step will output all kinds of cool details about the event:


But all we really care about is the statusCode of the HTTP call. As long as the group can be observed by the user responding, then the API will return a 200 OK statusCode. So, we hook up the output of the Get a Group step to another switch step which switches on statusCode:



Here is where things get interesting. I have a Duplicate Alert step and a Reassignment failure. We'll go over the Duplicate Alert step in a moment, but you can see this Reassignment failure step is hooked up to the Default Path. Huh? What's going on there? That is a second form I created to handle all the statusCodes that aren't 200. Like the 404 Not found, which might happen if autocorrect strikes again or your cat sat on your hand at a critical moment.

Anyway, duplicating an alert is actually pretty easy. We know we have all the properties because the trigger of the flow has them already. And the recipients we got from the annotation.comment the user entered, which we know is a group that exists. 


So now, when I get the notification:


I can also see in the comments in the Tracking Report, who forwarded it, and when:


I've attached the Workflow used for this article for reference or duplication, but if you want to add this functionality to your own canvases, you'll need:



  1. A new form, maybe call it Reassignment Failure to deal with notifying the responder that there was some failure in targeting the new group. 
  2. A response option on your "main" form. I recommend calling it something like "Forward" so your users know they will need to enter comments to target the group. 
  3. A flow triggered by event comments that contains in this order:
    1. A switch on Comments.annotation.response.response with a path for your Forward response option.
    2. The Get a Group (or if you only want them to forward to people, Get a Person) step. 
    3. Another switch, this one on Get a Group.statusCode with a path for 200. 
    4. A create xMatters event step to duplicate the alert hooked up to the 200.
    5. A create xMatters event step to trigger the Reassignment Failure form hooked up to the Default Path. 

This is a pretty basic workflow, and I can see a couple of additional items that might make it more useful: 

  • Add a check for People as well in case they want to be able to send to a person instead of just a group. 
  • Allow the comment to be in the format <Group> - <message> where "message" is a note to be included to the next recipient.

 If you're up for a challenge, try it out and drop a note in the comments. We love hearing from you!


Get a Group Step

Here's were you can get the goods for building this step. Alternatively you can import the workflow attached below. 


Name Required? Min Max Description
groupID Yes 0 2000 The unique identifier (id) or name (targetName) of the group. 


I've included most of the useful information from the API call so that the step can be reused in other situations, but this Reassignment stuff only uses the statusCode output. 



var apiRequest = http.request({
'endpoint': 'xMatters',
'path': '/api/xm/1/groups/' + encodeURIComponent( input['groupID'] ),
'method': 'GET'
var apiResponse = apiRequest.write();
output['statusCode'] = apiResponse.statusCode;
if (apiResponse.statusCode == 200) {
var response = JSON.parse(apiResponse.body);
output['id'] =;
output['targetName'] = response.targetName;
output['status'] = response.status;
output['externallyOwned'] = response.externallyOwned;
output['allowDuplicates'] = response.allowDuplicates;
output['useDefaultDevices'] = response.useDefaultDevices;
output['observedByAll'] = response.observedByAll;
output['description'] = response.description;

if (typeof !== 'undefined') {
output['siteID'] =;
Was this article helpful?
0 out of 0 found this helpful



Please sign in to leave a comment.

  • This is something we've really wanted. I'll try it out very soon. 

  • Hi Travis/Kevin. 

    I haven't tried it yet but like this for a couple of reasons:

    1) It provides a way to practice realistic scenarios with Flow Designer

    2) Its handy to have a solution pre-conceived when somebody says "I wish there was an easy way to hand this off to someone else...."

    I'll give it a try


    I tried it and it worked perfectly.

    It helped me understand the distinction between Comments.annotation.response.response and annotation.comment properties.
    I also like the fact that duplicating the event is simple because you already have all the properties.