Moving an Event to a different team

Not Yet Reviewed

Hi xMatters gurus,

Here is the use case:  

A event comes into a team1 (could be directly to a group or could be an inbound integration that pushes to the specific form/group)  The on call team member Acknowledges the event and takes ownership.  On closer examination the team member realizes that this belongs to another group/comm plan.  

At this point, the team member could use functionality to duplicate the event and send it to a new team (i.e. ).  The downside is that there isn't really a positive feedback that the new team got the issue and acknowledged that its their hot potato.

Instead is there a way to move that exact event to the new group/form/comm plan so the new on call person can Ack it and the issue can be tracked?





Date Votes

Please sign in to leave a comment.

  • Hey Kirk!
      Technically, no, we don't have the ability to "reassign" an event. Aside from the APIs, the hard part is correctly capturing the group name from the user. Users can respond with a comment in the mobile app, but then what if they don't enter the group name correctly? What if the group name has spaces? How do we parse the group name from whatever gibberish they enter? How would they reassign from a voice device? SMS?

    These are not insurmountable, but they must be thought through and it will depend on your audience. If people can't regularly type something like "Reassign: THIS IS MY GROUP NAME - and here is a comment", then this could be frustrating to users. 

    Depending on how complex you want to make it, I see two approaches:

    1) Capture free text response from user. This would only work when they respond via mobile app. But provides maximum flexibility (and headaches)

    Take the items in the post you have above, but add a couple things. 

    First, add two new properties to the comm plan and the relevant form layouts called "reassignment" and "reassignment_display". Then, update your email/mobile message html content to display this Reassignment value only if "reassignment_display" is set to visible. This is easy to do with css using the "display" directive thingy:

    <div style="display: ${UUID1}">Reassignment from ${UUID2}</div>

    Where UUID1 and UUID2 are the UUIDs of the reassignment_display and reassignment properties respectively. 

    Sandra has a good article that explains this magic here, although she is using it for coloring, but the idea is similar - use one property to drive the style of an element. 

    2 - In the Outbound integration script that will generate the new event, set reassignment_display="none" and then check if the response is for reassignment and as long as we're here, we'll add some edge case checking. Something like this:

    if( callback.response == "Reassign" ) {
    // First, make sure the responder actually entered something in the comments (an annotation)
    if( !callback.annotation ) {
    // Do something here to tell them the reassignment didn't work. Probably
    // generating a new event is best.

    // We'll assume the entire comment is the group name.
    var groupName = callback.response.annotation
    var payload = {}
    var properties = callback.eventProperties;
    properties.reassignment_display = "visible";
    properties.reassignment = groupName; = properties;

    payload.recipients = [ { targetName: groupName } ];

    // add the rest for creating the event here


    That should do it. One problem I see though is that we need to initalize reassignment_display to "none" for every other event that comes in. There might be a way to do it with CSS I wonder. 


    2) Hard code the choices. This would work across all devices but doesn't scale well.

    Just add a couple new response options to your form

    • Acknowledge
    • Ignore
    • Reassign to Help Desk
    • Reassign to Software

    Then the if block in the outbound integration just becomes:

    if( callback.response == "Reassign to Help Desk" ) 
    groupName = "Help Desk";
    else if( callback.response == "Reassign to Software" )
    groupName = "Software";
    return; // Do nothing

    var payload = {} = callback.eventProperties;
    payload.recipients = [ { targetName: groupName } ];

    // Add the code for creating the event

    And this is then available across all devices, voice, SMS, email, etc. 


    Thoughts on either?

  • Hi Travis,

    Quick thoughts:

    1) (use  is likely the most flexible but its a little limiting since someone has to use the mobile app.  Are there plans to include the annotations into at least email?

    2) Is this forwarding an event or duplicating it?  I've done some work with duplication already that is close to what you have up there (lookup from a list of other groups...).  I completely agree that maybe 3 or 4 groups for forwarding is ok...ish, but 20?  Not so much.

    One idea there (with event duplication) is to include a "routing history" in the outbound to be included in the duplicated event so you know the path of the issue took before it got to you.



  • 1) No plans now, I opened PM-5186 to request this on your behalf, but I can't yet speak to any kind of time frame for it. 

    2) This would be duplicating it. The code above would go in an outbound integration script and would need to terminate the previous event. 

    Yea, you could include a "history" property and just keep adding to it for each new event. Similar to how the reassign is handled, except just append the string. 

  • Thanks Travis,

    Yes, and you would likely also want to terminate the original event, otherwise they'll just just multiply if the "hot potato" gets moved around alot, even back and forth between teams.


Didn't find what you were looking for?

New post