hello everyone this is nature a senior solution consultant at servicenow specializing in security operations uh welcome to the second episode of dashing through the workflow in today's episode I want to go over flow designer now if you've ever been involved in a conversation with any servicenow consultant or if you've been generally looking for ways to optimize your operations you must have heard of the word workflow and most likely you also heard the word flow designer now flow designer is literally where all of the workflow magic happens it is where we design different workflows to be able to do things anywhere from automating a single task to automating an entire system process now whether that was with security specific or not I want to take you on my slate today and I want to take you through a journey to explore the slow designer okay step number one would be accessing the flow designer now flow designer is going to be limited to specific personas um limited by their access rights so to be able to modify create or or uh just view the different flows that exist on your cell service now instance you must first make sure that you do have the appropriate access rights which could change based on um what is the reason for you to access the flow designer is just to view it is to be able to view and modify these different flows is it the able view modify and publish these different workflows so please make sure that you have the appropriate access rights for that and to generally access the flow designer similar to accessing any servicenow application we go into the filter Navigator and just look for flow designer and as you can see under process automation we get the flow designer which usually opens in a new tab now within flow designer we have flows which basically um are the full-on workflows that are able to start from point e a and and all the way and point Z sub flows are going to be miniature flows where we can basically take some um flows that we are intending to build but rather than every time we want to start with acknowledging the alert rather than we create that specific task every time we can just create a subflow for that and later on utilize that specific subflow to build the flow on we also have the different actions uh so is it going to be to add a pose activate a specific plugin add a comment add an application to meeting Etc all of these are going to be specified as actions we also have the different executions so how many flows have been executed the runtime who created them the state they are in Etc um here's where we get to see the different connections that can be tied to the different workflows so we can see the Google underscore NL is configured in this case in the case of My Demo instance right now the ad is not configured if there is a specific one that we're looking for for example maybe OCTA we can see if there is a connection for that specific application or not and the help button is basically going to allow us to see the documentation see if there are any other videos that have been shared uh Community discussion integration Hub Spokes and different courses that allow you to actually be more proficient within a flow designer now let's go ahead and jump and look at the different flows now when it comes to building specific workflows it goes down to what is your specific preference on your organization and how you want to utilize a different functions within the flow designer now we can go ahead and actually start a new flow right from the get-go and just say we want to name this in the case of this I'm just going to call it test and then write a description test the Low designer application this is where we get to specify do we want to actually have it Global for every module within our licenses uh or or if we want to just have it specific to one of the applications within the platform so is it specific to the same DB is it specific to itsm is it specific to security um in the case of this demonstration I'm just going to keep it keep it Global uh the protection we can keep it to read only or none in this case I'm just going to keep it none and do it or how are we going to be running it are we going to be running it as a user who initiates the session or as the system user um so this is just a matter of preference again I'm just gonna keep this as the system user and we're going to go ahead and click on submit and then we can see how we can just utilize the different actions that we have pre-built on our home page so if you remember I've already gone through that but we can utilize these actions here we can look for the specific action uh from there and just add it to the workflow that we are building right now so maybe um create a record I'm just gonna take that and add it to the flow that I'm building right now um another thing I can do is add a trigger when do I want the specific uh workflow to actually be um start kicking in is it upon receiving a specific incident is it upon clicking a specific button or is it upon a specific update or is it basically because we have an SLA associated with the um task that the flow is going to be running for so all of these are things you get to determine yourself while you are building these different workflows another way we can go about building these different workflows is through utilizing the workflows that come out of the box so depending on which application you have a subscription for within servicenow some of the licenses actually do come with uh workflows out of the box so we can go ahead and maybe look for a specific set hops workflow uh let's go ahead and say the secops Sam VR specific workflow we it looks like this one uh as soon as there is a change request created or updated we update the change request record we wait two seconds we look up the approvals Etc now if there is a specific workflow that I'm trying to build where it's going to utilize a lot of the different actions that are already existing within this specific workflow I can go ahead and copy this entire flow paste it on a new flow application designer and then I can just modify the tasks that I want to actually modify and just kinda rather than Reinventing the wheel utilize what I have already been given to um just make things easier for me um another thing we can do is that if we know that every time we're going to be maybe creating an incident or waiting for a specific alert to be um ingested into service now to kick in a workflow rather than me building that within each of the different flows I can just create a subflow for that and every time I want to build a workflow that depends on that subflow just called that subflow in my test environment okay now let's go ahead and build a test security workflow the test security workflow is basically going to send out an email to the admin every time a user attempts to log in their account so many times that it fails and sends them a notification to their personal email saying that they have failed access to their accounts so to start off I'm gonna specify the trigger that if we receive an inbound email with the subject containing the word failed and if we want to we can even add any other specific um conditions maybe we want the actual body text to contain the word password as well and then we are going to specify an action from the servicenow core that's gonna send out an email the email is going to be sent to the admin so let's say admin at service now dot com and maybe we want to BCC the user that actually is part of that login uh attempt so we can either fill out the information or use a data pill in this case I'm going to use the data pill and we're gonna call the information from the trigger initiated the workflow we're gonna specify the email record and we are going to say it is from the recipient the subject is we can specify a subject for the email in this case I had it as a user is accessing from a suspicious location and then later on also specify what is the body of the message in this case I just said a user failed to access their account now servicenow in general is a low code to no code so if there is a need for you to add a specific code within any of these different um Fields you actually have the option of looking at the code and modifying it after that we can click on done and if we want to we can even add multiple actions or uh call for another subflow so in this case I'm going to call for the subflow that is that allows to just do a password reset now another thing we can do is if we have an integration with any um other spoke we can actually call on that spoke so if we wanna for example maybe uh send a teams message to the security Channel or slack or whatever is the spoke that we want to utilize in this case we can specify that and each of these different spokes are going to have different function based on what is the integration that is created and what are the limitation of that integration as soon as we're done we can just go ahead and activate that um workflow test it out save it or send it out for review that is dependent on how you want to set up how the different flows are going to be executed within your instance I want to piggyback on what we talked about in the last episode building integration using the rest API Explorer to do that I'm going to show you how we can utilize the flow designer to build workflows from or are going to be connected to the integration that we possibly can build using that trust API Explorer very similar to building a regular workflow so filling in the information for the flow we are going to go ahead and submit now as soon as we get that uh we're gonna start with the action in this case I'm going to go ahead and say that the action is going to be um servicenow core creating an incident it's worth mentioning that we can also use the rest API Explorer to actually connect to other services by having servicenow as the Common Ground between them so for example if I want to maybe send a steams message every time we receive a trigger from the API that we built or send the slack message or something of that sort I can go ahead and build a workflow for that from the servicenow instance so I can go ahead and say here we go um so we can actually utilize that or utilize any of the other integration jira Dropbox Etc uh in this case again I just want to stick to the um Basics so we're gonna go ahead and say we're gonna just create a record now let's go ahead and modify the trigger and that's going to help us fill the information for creating the record um here so adding the trigger we're gonna specify that the trigger in this case is going to be coming from the rest API now depending on what we want to do once we receive that trigger um are we going to be creating are we going to be just getting information are we going to be deleting are we going to be updating Etc we can get to decide the HTTP HTTP method that we want to utilize in this case keeping it simple I'm gonna show you post now it's is worth mentioning depending on which HTTP method you have uh some of the information that you're seeing on the screen here might change now uh if you notice since I have the HTTP HTTP method as posed we get to see what is the request content now if I change that into get we notice that that specific field had disappeared because there is really no need for it so um depending on which HTTP method we have the information on the screen might change now the path parameters here is going to be also dependent on the integration that we had built and what information are we really uh getting from that specific API so um I'm Gonna Leave the field here empty uh but in the case of your specific flow you should fill that out based on where you're getting the information or where you want to add the information now in the require authentication um check box here if it is checked that basically means that we are going to be waiting for an authorization and that authorization is going to be coming from a specific role here you get to specify which role gets to do that authentication if I add a role here I get to either specify to an admin someone um I specifically have to approve or reject these different authentication requests so depending on who has that role and then in the certain profile they would be able to approve or reject these different requests now the header field all the way down here is basically going to define the header to be send in the inbound request so we get to actually specify that here ourselves is that going to be a string a number a true or false is that a mandatory field or not this is all something you get to determine based on what are you trying to be doing query parameters are going to be the information that we are getting we can have multiple query parameters so in the case of here if I want to maybe create an incident I can go ahead and say I want to get the description um I want to get the uh maybe if it is a security incident the IP address associated with it or if it is a security incident I want to add in a query label to know which integration specifically pull that information and created the record on my servicenow instance so here's where I get to do all of that so the path parameters that we add in here are basically going to be the substitutions that we want to add to the endpoint URL when we are actually sending out the request now once I specify all of this information I can go ahead back into the record that we created and then I'm gonna be able to basically specify which table I'm creating that record on so if we want to have this as a regular incident we can just type incident if we want to have this this incident associated with maybe a security incident we also have the option to do that over here but again just keeping things simple I'm going to keep this as an incident and then the fields that we are going to be adding to the incident like uh the description um again back to the example of an IP address the IP address uh the assignment group all of that this information we're all going to be getting from the rest API so um depending on which query parameters that we add in here these are going to be the information that we later on can add it to the appropriate fields in our servicenow instance so for example if I have a description in the rest API that is not titled as a description but it may be titled as more information or something of that sort that later on I can utilize as a description for the incident I can go ahead and just specify the query parameter here and later on call it back as an incident description same goes to all of the other information what we're doing right now is basically we are telling the system how to parse the different information that we've created queried from the rest API that we have built now similar to any other flows really we can have a bunch of different actions happen to the incident that we created from the rest API so for the example here I have already created an incident uh decided the parameters all of that I can go ahead and add a subflow and that subflow can actually be a subflow associated with another rest API connection or I can have an action that is also associated with another rest API connection so this just shows you how we can utilize it to the servicenow platform as the common ground where we are connected between all of our other devices and services that was just a quick overview of the flow designer I just wanted to highlight some of the different features within flow designer and how we can utilize them in our advantage if you have any questions regarding how to run flow designer or any of the features within flow designer please feel free to reach out to you your servicenow expert check our documentation site or check our community site hoping that this did provide you with some value looking forward to seeing you on future Dash include the workflow episodes uh happy holidays everyone