1. xMatters
  2. Community
  3. General Q&A

Subscriptions - Making them report state changes

Kirk Friedman
Not Yet Reviewed

Hi All!

I think subscriptions need to be internally hooked into the state and responses of an Event.  When we got subscriptions working, we saw that they only occurred when the event was generated. Here is a use case for state updates:

As a devops practitioner or manager I want to get a one way notification when an event occurs.  That way I can be aware of it and take action (or not) as the case requires.  I need to keep track of the state of that event, including the responses of people that the event went to.  This is especially true if the event is being closed and another one opened for transfer to a different team/group.

While it is certainly possible to embed the event Id into the original subscription notification, I don't want to have to look up the 12 events from last night by URL or event ID to see that 10 are terminated/fixed, one never got a response and one is in progress.

It is also true that the Activity Update allows a user to get notified when an event is opened and when it is closed.  That covers about 80% of the above (I still don't know why an event is still open).  But it requires someone with developer credentials to add me to Activity Update section of the Communication Plan.  One very strong point of subscriptions is that once I, a developer have created the subscription form and shared it, people can add themselves, set their own filter patterns and so forth without needed to get a developers help.

So, is there a way to get subscription notifications on the change within the event itself.  Or is there already a way to do that?

0

Comments

5 comments
Date Votes

Please sign in to leave a comment.

  • Travis Depuy

    Hey Kirk! Good questions. I was going to point you to the Activity Update, but sounds like you found that. I do see your point about needing developer access though. 

    I opened PM-5269 to get that to the PMs. 

    I think we could do this with the integration builder though. It would require 2 new Outbound Integration scripts per form you wanted to "track" though. Here is the general idea:

    1. We create a new Comm Plan with a form - Call it "Activity Updates". Add a subscription form. We might need to think about what properties go here. "Event State" would be a good one as a list with "initial" and "terminated", and the rest found here. Also "Response" as a text property. We should also have the "Form Name"
    2. Create a new Outbound Integration script that fires on event status on the form you'd like updates on. This will run a script to generate a new event for the "Activity Updates" form. 
    3. Create another Outbound Integration script that fires on response on the form you'd like updates on. This one will run a script and generate a new event for the "Activity Updates" form, but will send the value of the response. 
    4. You can then create a subscription targeting yourself with Event State "initial" to be notified about new events or a subscription with response contains "Reassign". 

    Since we created a new Comm Plan, we aren't tied to the original Form and you can then repeat this for any other form you'd like activity updates on. 

    That might work. In theory?

    0
  • Kirk Friedman

    Hi Travis,

    Couple of questions:

    1) Are steps 2. and 3. above the same step?

    2) So my root Comm Plan has an outbound integration which creates a copy of the response and sends that to the Activity Update comm plan.  Would you use the Activity Update form's API to get access to fill it out or some other API/UUID?  

    3) or would my root Comm Plan send over the copy to the Activity Update comm plan, inbound integration URL and have it do the copying into the Activity Update form?

    4) Regardless of 2) or 3) we've created an event that will need a destination group and will have a timer associated with it right?  If so, then something has to kill the Activity Update event right?  I guess we could let it kill itself (set a very short timespan), but isn't there a more graceful way?

    All of the above being said, this does appear to be one way to support subscriptions with details. A fair bit of work to try out.

    Thanks,

    Kirk

     

    0
  • Travis Depuy

    Howdy.

    1. No. One is for the event status and one is for the notification response. We can't fire the same script for event status and notification response, so we need two scripts. 
    2. Yea, I think it would be fine to just send the POST /trigger directly to the Activity Update form. (EDIT, see #3)
    3. Actually, I think it might make more sense to just send the root comm plan's event ID to the Activity Update inbound integration script. Then let the inbound integration pull all the details from a GET /event. This would help make the Activity Update stuff more generalizable so you could use it for almost any Comm Plan
    4. It really depends on what makes sense. We could set it to have a short expiration, or we could kill it after the root comm plan's event terminates. When would you like the Activity Update event to terminate?

     

    Yea, there would be a bit of scripting and tinkering, but I think it would be doable. 

    0
  • Kirk Friedman

    Hi Travis,

    Regarding 1.  I see.  One to handle user responses to an event.  The other to handle automatic changes like timeout->escalations, or termination because the overall timer has expired.

    Regarding 3.  Good idea.

    Regarding 4. above.  We are talking about using the Activity Update comm domain and integration strictly as a receiver so that folks can pend subscriptions on it to receive info about the original root comm domain event.  I think the Activity Update event itself is throw away.  Not sure whether that means it should immediately terminate or give it a quick expiry time.  Your thoughts?

    Thanks

    0
  • Travis Depuy

    Yea, the activity update event just needs to hit the subscriber's device(s) just the once, unless you want it to escalate through devices and/or people in groups I would just have it expire after 5 minutes or so. 

    Crap, I just realized there isn't a way to pull the form name from an API call. The GET /event will get you the form UUID, but that isn't terribly useful because we don't have a GET /form. So, I think your scrips in steps 2 and 3 in my original comment would need to hard code the form name when creating the Activity Update event. When you copy/paste this code into a new "root" comm plan you'll need to update the form name. 

    Then I would have the "Form Name" in the Activity Updates be a list property so that people don't have to know EXACTLY the form name and can just select it from the drop down. I added PM-5277 to sort out a way to get the form name from the API (you guys are on a roll lately!). 

    0

Didn't find what you were looking for?

New post