Moving an Event to a different team

Please sign in to leave a comment.

• 

  Travis Depuy

  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;
    payload.properties = 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";
  else
    return; // Do nothing
  
    var payload = {}
    payload.properties = 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?

  January 20, 2017 22:43

  0
• 

  Kirk Friedman

  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.

  Thanks,

  Kirk

  January 20, 2017 23:12

  0
• 

  Travis Depuy

  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. 

  January 20, 2017 23:56

  0
• 

  Kirk Friedman

  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.

  January 21, 2017 00:44

  0