I have some thoughts on the Flow Designer.
1.) Say there is a custom Response to create a ticket (ticket Created). a few hours rolls by and the tech would like to update the ticket or even add a note extra custom ideas come to play .
flow --- =)
User has xMatters app/email to click to response comment to update ticket event
Flow= createSnowTicket ---> (gather INC data post to Teams/Slack) --> 2 hours later tech arrives on site and either checking into site would like to click a different Response to update ticket)
on another custom response i would like to update the Current Ticket but i cant do it since its a different response trigger .
i was thinking of maybe a Switch in front (so if INC is not created and action=x then go directly to that part of the Flow but then no VARs are there to modify.
i thought of pushing Update Ticket response directly by taking the step and bypassing create and other flows but states step already connect. would be cool on if/then logic to attach. im sure there are updates coming to play with it as well.
I almost would like to look at FLow Designer at the beginning of an integration to have it from start/finish when to control the inbound/ first message to then post all the parameters we gathered such as Incident ID and on the fly modify group to send to.
thanks
Comments
Please sign in to leave a comment.
Oh Definitely the HTTP trigger i hope was coming soon. its like having a new fun toy to buildon.
utilizing http to trigger x like email notifcation and ill be curious if waiting for the response of email/txt in the same flow could you control it there (and if that email response would be the same EventID to then track it to flowID not sure if its all 1-1 now or can it wait for response say 1-3hrs later. but i can see some power on flow-flow start-end control.
Though one of the main questions in this post is that i was trying to get is if the flow is activated again from the user options. Say keep the Flow Variable to a global level and be called on again.
say 4PM issue comes in triggers flow .
flow-Creates a snow-ticket and updates xmatters App with ticket info
now its 5PM tech is onsite and with the response options add comment to ticket. and maybe 6PM to close ticket from xMatters options
(but to get that sys_id) is there a way to tee that on a response inbound like flow navigator and drag the Comment / Close ticket option later in the flow (if x is this) so then if flow is called again from a response opiton it already has the outputs from that initial ticket creation. going the full flow from start-end
thanks
Currently it works this way:
4PM issue comes in, an event is triggered in xMattes, and there is a response option to open a SNOW ticket.
Response option is selected to trigger the flow that opens the ticket. (At this point the original event and flow are done).
The ticket that is created triggers our SNOW integration, which starts another event in xMatters to assign the ticket to a user. The user is able to accept the ticket and add comments. You can either choose to leave that event open in xMatters to allow the user to respond again to the same message to close the ticket, or you could close that event, and start a new event in xMatters with the ability to close the ticket.
There is a trick to closing tickets in the latest versions of SNOW - you have to provide some sort of closure explanation (I forget what it is called). I don't think older SNOW customers have this requirement turned on by default, but newer customers do. Assuming this closure explanation is a text field, you would either need to use the comment trigger to close tickets with a "Close" response and use the comment as the closure explanation, or hardcode the closure explanation.
ahh i see so its really a flow at that time from my the original start of the flow integration.
sooo if i cant do that maybe I was curious if say i stream a log to a system then to capture all the current FLOW xMatters INC ID and $VARs in the jSON payload in a to say splunk and then i could i then go back and trigger on the same flowID/xMatters IncidentID to enrich it and have a different build based on response so to the user its all. what would be cool is getting the xMatters app interactive from start to end of incident management and at times give users different options in xMatters app based on input . might be to tricky
Ya the SNOW closure Piece for incident i might create custom script to give more control on our custom SNOW to add additional input/outputs since we have Snow instance that isnt out of the box more custom done. I originally have created a 2way integration from my splunk but this Flow designer magic piece brings alot of cool possibilities.
what i was originally doing on Splunk integration was create the Ticket from splunk and i would get the data back in splunk from SNOW realtime since we get the INC table and then with that Create the xMatters alert with the ticket information on our automative option off hours. With this flow we could give the control back to the engineer working that potential issue so brings alot of value in a full end to end incident management. :)
thanks
One other thing you could do is create a new field on the incident table in ServiceNow to hold the xMatters event IDs. Then when you create a new ServiceNow incident from xMatters, you also add the event ID to this new field.
Then, later, whenever, you can query the incident table based on the event ID field. I'm envisioning this field as a comma separated list so that you can have multiple event IDs tied to the same incident. And each flow knows what event ID it is from so it just queries that field.
Lots of ways to make a hat I suppose.
Happy Thursday!
ya i was trying to get it all in the flowy designer way hehe kinda way to keep the VARs able to retrieve at a later time if/later in the response chain and if that response is triggered later in the chain take that connect point in the middle of say flow with a switch...
But with splunk and other tools cause in my case splunk holds all the info its easier to send different payloads to different triggers too.