hey everyone welcome back to another go with the flow the series where i teach you servicenow flow designer with as few edits as possible with as few edits as possible with as few edits as possible with this few edits today we are going to take another example of something you would typically do with code but instead we are going to make a simple reusable flow action that can be deployed to anybody who uses flow designer including local developers the use case is going to be firing an event now developers are already familiar with gs event queue and gs event queue scheduled if you're not familiar with these development concepts there is going to be in the top right corner a prompt to two videos that i've done on these topics they will also be in the description below be sure to watch those will give a ton of context to this video that being said events are super awesome they allow you to trigger conventional notifications because i hate using send email from flow for reasons we'll get to in another video second an event can trigger a script action which is basically like a business rule that runs off of events and third events can be scheduled into the future with event queue scheduled which is also awesome now experts might be saying robert i don't need a flow action to create an event for me i could just use an existing flow action called create record and dump the record into the event table and you're absolutely right you can however you are probably somebody who is very intimately familiar with service now behind the scenes in the back end you might understand how that table works and how to instantiate records into it um but others might not in fact most developers probably won't because they're using the gs event queue and event queue scheduled functions in order to dump to that table in the first place so yes you can but it's kind of ugly and it's not something that we can simplify for other users so we're going to create a simple reusable flow action so here we are at our little flow action home we're going to click new action we're going to call this create an event let's figure out what kind of things an event needs before we start developing the action according to this page on docs which i'll have a link for in the description uh using the gs.event queue requires the event that you want to trigger the record it is triggering from in this case current and two parameters that you want to load into the event now if you watch the two videos i posted earlier on event queue that's going to make a lot more sense if you don't please go watch those videos i've gone ahead and i've created an event just for this exercise they called it incident gone critical i'm imagining some kind of world where we may want to trigger some kind of event-driven notifications if an incident works its way up to a priority one okay let's go back to our flow action and start establishing inputs based off of what we know of the event so we know for sure that we need to have the event name so let's call it and let's create an input called event and it's going to be a reference and this could be a reference to what is going to be a reference to the event registry so we can pick an event as an input so i'm looking for the table of event reg there we go event registration and we need to make that mandatory otherwise why are we doing this in the first place then i'm going to create another variable called table we're not going to keep this all the way to the end it's just something that's going to help us uh troubleshoot and test this which you're going to see in a second and that's going to be of type table we're not going to be needing that mandatory now we also know that we need a record that the event triggers from so let's create an input called record and it is going to be a document id a document id is kind of like a reference except it gives the table as well it's kind of a way to sing here's a record from the whole servicenow instance otherwise we'd be saying table and the tables reference okay so that's going to be mandatory because we need to have a record then we know we need two parameters so let's create two parameter variables as well it's called palm one it's going to be a string and we're going to create part two and it's also going to be string neither of those are going to be mandatory all right let's save it here and let's add a script step okay so the way we add a script step is just hitting this plus sign and we're going to script step and let's call this launch event script as you may have known from the previous action we created in go with the flow you need to map the inputs from the main action into the inputs at the step level okay so it's gonna feel like you're duplicating work but if you had a flow action with multiple steps it would make a lot more sense so let's just start mapping those inputs so we're going to create an input for the script i like to make sure that my variables are named differently so i can tell at a glance like which ones i'm talking about so these ones can be the variables for the script so i'm going to say script event and script event is just going to be the event name of the event reference that we've already got as an input at the top of the action okay we also need the event record so let's go script record and not surprisingly we're going to drag that from our input variables the record bam now we're going to do the same things with those two parameters so script arm 1 what do you think that's going to be i think it's going to be the input variable par one excellent you're right thank you very much now we're going to do the same thing for number two part two and we're gonna grab parm two now all of our inputs are mapped let's save that it's time to put in some scripting code all right so we know we want to just trigger the gs event queue so gs.event queue is going to be the function and we remember that it's got those four parameters which we're just going to feed it with our inputs for the script so we've got inputs dot script event that's going to be the first parameter second parameter is going to be inputs dot script record third parameter is going to be script inputs dot script parm1 and then the last parameter is going to be inputs.par 2. so just like the doc said we had an event a record two parameters inside our flow designer we've got the event the record and two parameters let's save this okay one last thing before we test i'm going to go back to my inputs and i'm just going to do this thing on this record i'm going to make it depends on table and this is for testing purposes because under normal circumstances i would put this action in a flow and that flow would provide the record which de facto provides the table that's how document id works okay in this case we are going to need to explicitly tell it a table before we can select a record and that is only true when we're testing the action it won't be true when we're actually pushing this into a flow so let's go ahead and save and test it sorry let's save it first and then let's test it okay so what event are we gonna do we're gonna do the incident.gone.critical again just for testing purposes we have to tell it a table explicitly before we can get it to allow us to pick a record so we're gonna pick any incident that we want and perm is gonna be this is a test test number zero zero one and let's run the test let's view the execution details and let's see what happened in steps okay let's see all the variables it came up with so it knew the event was right part 1 is right part 2 is right and it looks like the record it figured out what that one is as well so let's go to see our event queue here we are in the event queue and we've seen an event that's been created with the proper event and proper parameter one proper parameter two so we know that the script action has been successful now let's ramp up the complexity a little bit at the start of the video we talked a little bit about gs event queue and also gs event queue scheduled you might want this event to be thrown into the future to process at a later date and we want this action to be so simple and so scalable we'll just ask them and if it's schedulable we'll run gs event scheduled instead of gs event queue it's going to be so awesome so we're going to create another input here and we're going to call this scheduled date and it is going to be a data type of date time and it's also not going to be mandatory the game we're going to play here is if it's populated we know that's what they want so we're going to save that so let's create another input let's say script scheduled and that will be the scheduled date we'll map that to so if inputs dot script scheduled and this is kind of like a way of saying if it's true if it has a value if it doesn't have a value this will evaluate to false if it does have a value it'll evaluate to true so if that's true i want to let's copy this and let's paste that in there else we're going to follow the normal instructions sorry i wish this was not here can we collapse that collapse this there we go okay so if there is a script scheduled date then we want to do event queue scheduled i'm going to save you guys a ton of troubleshooting what i found is that you have to make sure that this thing is a date time so we're going to force it to be a date time even though we start at the start that it's a date time so we're just going to create a variable called date assurance okay and if that date variable is populated we are going to set date assurance and is going to be equal to a new glide date time on inputs.scheduled so what that'll do is make sure sure that script scheduled is a date time and then at the end of gs event scheduled there's a last parameter which tells you what date and time it's on we're going to drop our date assurance variable into that so now what we've got is logic that says if there is an entry in the script scheduled variable if they bother populating it then run gs event queue same way we would but scheduled this time and put that date assurance in there to make sure it goes to a date okay let's save this and let's run a test again we're gonna which test we're gonna do the incident gone critical table is going to be incident record is going to be whatever incident we want parm one this is a test test zero zero two and we're gonna populate a schedule date and we're gonna make sure this is in the future so i'm going to pick like june 10th at 505 a.m let's run the test let's view the execution details let's see what happened in our steps so we see that the event is a proper event the parameters are correct the script record is great and it understood what script scheduled was so it should have followed the right path the only way we're going to know is if we go back to our event queue let's check that out let's refresh it and there we are we have the event we have the parameter one we have the parameter two and it's set to process on uh zero six zero nine at five in the morning all right we have an awesome new flow action let's publish it and now that it's published we are going to give it a more full test so i have created this flow called incident change to critical and whenever an incident bumps up to p1 i wanted to fire this event so let's get rid of this old create event record where i was putting around trying to create an event queue the hard way so delete that add a new action there's our create an event action i'm going to pick that okay so first things first we need to pick an event as always incident dot gone dot critical and we're gonna drag a record into there it's gonna be the incident record that this trigger is based off of it auto fills the table and in fact once you start moving these into actual flows you can take that table out this record is go when we drag and drop a record into it we'll send all the information you need you don't have to have that table variable anymore so part one this is a test and this is gonna be test zero zero three and we're not gonna bother with the scheduled date this time but this test is better because this is the action embedded in a flow not just a test of the action itself so let's click done and let's save this flow and let's run a test which incident record are we going to pick let's pick 331 run the test view the execution details see the create an event let's see the steps it understood what everything was it understood that there was no script schedule date let's go to our event queue give it a refresh and there's the event got the correct parameter the correct parameter got the right incident in there and it's processed on right now because we didn't load it with a scheduled date and there you have it folks you've taken everything that devs used to have to do with gs event queue and gs event queue scheduled and you've now empowered low code users to use that function in their flows how awesome is that meet me on the next video where we are going to talk about the proper way to send notifications from your flows and it's going to depend on the gs event queue we just built here thanks so much for watching everybody we'll see you on the next one if you're a servicenow expert looking for better opportunities but maybe your resume or linkedin profile isn't doing you justice reach out to me via linkedin or the email pictured here as i offer both career coaching and recruitment services and if you're a servicenow customer or partner you heard that right robert fedoric now does servicenow recruiting with a 1 500 subscriber youtube channel and mailing list and thousands of linkedin followers let's make sure your open positions get first go with the prodigious pool of servicenow resources reach out via the email picture here