Name: An Admin’s Guide to ServiceNow Flow Designer
Uploaded: 2026-03-10T17:31:42.723Z
Duration: 1 h 8 s
Description: An Admin’s Guide to ServiceNow Flow Designer

Transcript for "An Admin’s Guide to ServiceNow Flow Designer": Hello, everyone. Welcome or welcome back to another Now Ben webinar. This time, we will be diving into ServiceNow's flow designer. Before we get started, just a little bit of house keeping. This session is being recorded, and this will be shared with you in our follow-up email. You are in listen only mode today, so please do engage in the chat. It's great to see so many of you excited for today's session, and I'm pleased that the chat is functioning as it should be. We've had a little bit of tech difficulties, so I'm glad that it is functioning properly. And there will also be an audience q and a at the end of the session as well. So if you do have any questions throughout the session, then please do pop your questions in the q and a tab, and we will get around to as many of them as we can. The end. Fantastic. So at NowBen, we're here to support the ServiceNow Community with content that helps you understand what's happening across the platform and where it's all heading. And that means looking at the bigger picture topics like business direction and acquisitions whilst also exploring the technical side as well in a way that feels practical and relevant. We also want to bring in thought leaders from across the ServiceNow Community space to share best practices, practical advice, and real insight to help you grow your career on the platform. And we do this from over we do this in a variety of different ways. We've currently got our newsletter, and we also have articles on our website. We've got the webinar that you've that you've joined today, and there'll be a lot more coming soon as well. So these webinars are, of course, as I mentioned, a part of that wider vision and is definitely something that we're really keen to continue building at NowBen. We really appreciate you being here and spending your time with us today. But without further ado, I would love to welcome our speakers to the stage. Today, we've got Hardeep Singh joining us, a ServiceNow technical architect, and Salma Shaikh, a ServiceNow tech lead. So I will hand over to both of you so we can kick start the session. Hello, everyone. I'll ask Salma to actually start with her introduction as it's ladies first, and we had women's day. So by the way, happy women's day to everyone. Thank you, Hodith. Thanks, everyone. Thank you, Saima. So I am Selma Sheikh. I have been into IT for more than ten years and into ServiceNow space for more than five years. I have started my journey as a presales consultant then into mobile and web application developer. Finally found my soulmate in ServiceNow. So yeah. I've worked on various ServiceNow modules, ITSM, IRM, CSM. Currently exploring FSM too. So that's all about me, Hadith. Right. Thank you, Selma. My name is Harjit Singh, and I have overall fifteen years of experience. And I have worked for more than, I think, twelve years in ServiceNow. And I started my journey as a HPSM developer, if you guys are aware of that. It's not anymore in the market, so ServiceNow has taken all their clients. And since then, I have been working as a ServiceNow developer, then I became a consultant. And now I'm working as a technical architect in one of the big four organizations. And I think, like Selma said, I have also fallen in love into ServiceNow because I think the kind of platform it provides us to implement the things is really amazing, as well as the way it is automating every single day is also great. Lastly, I think, whenever, we want to learn something new, there is always something on ServiceNow, so that's the best part, I believe. And I think we can start. I'll share my screen quickly. So, Selma, let me know once my screen is visible. Yes. Yes. Screen is up. Right. Okay. So as you guys have registered, you would be aware we will be going through the flow designer fundamentals today, and it is for people who are into admin role or they are actually a developer also, and they have been scripting all their life. And they haven't seen what amazing things ServiceNow has introduced in, I think, 2019, I believe. And after that, after many iterations, I believe, ServiceNow has finally made this flow designer, I would say, usable. Earlier, it wasn't. But now it's where everyone is recommending using flow designers. So we will be going through the introduction, the fundamentals. We will see some basic examples, hands on, and we will be looking at couple of advanced concepts, and then we will look at a real world use case. This will be actually amazing. Then we will, at the end, look at the best practices. And finally, we will have some time for q and a. So let's start with what is a flow designer. As we know, ServiceNow is for automating all the business processes, and we were doing already that. Right? We were doing it through workflows if you are, like, old like me. So we were doing it through workflows. We were doing it through scripting and all. Right? But I think it was a great, introduction when ServiceNow introduced flow designers. We were not happy, to be frank, at that time because it wasn't matured. It was their first version. But I think after a couple of years, it has been, I would say, at par, and now everybody is using Flow Designer. So this is basically a visual workflow automation utility as it says here. And here, you don't have to write any script, and you can automate any process. And you don't, it's just drag and drop, or you can just maybe, use some data bills, which we will see. So, basically, flow designer is for automating your processes. So adding to what Huddl had mentioned. Right? So, Huddl, to inflow designer, there is an ability to even code things. Used for developers who are into extensive coding as well as for the people who have not written a single line of code. Right? So that's the beauty of it. Right. So even if you are a citizen developer so in service now. terms, what are citizen developers who don't know anything about scripting? They can come and write business processes without even a single line of code. And like Selma said, we can also we have an option to even write the scripts. Moving on, let's take an example here. In your organization, you might have, like, thousands of processes. So I've picked a very, very basic example. Imagine that your organization is giving iPhone 17 for your business processes or business usage, and then you raise a request for iPhone 17, and it goes for approval to your manager. There are some notifications sent. When he approves, the iPhone 17 is assigned to you. Right? So this is a basic process, and all of this process can be automated in ServiceNow without writing even a single line of code, and we can do it in flow designer, which we will see later as well. Now talking about the benefits, like we said, low code or actually slash no code. So minimum amount of code is required or minimum knowledge of coding is required. After that, these flows are reusable, which I think Salma will be talking about later, how they are reusable. So these flows can be reused again and again at different places. Then we have automating in single platform. So all the flows which you have written, they would reside at this platform, and they could be called from any other tool as well. For example, there is a tool Jira or there is some other tool, Microsoft Teams or any other tool. All of those tools can also call these flows. And then whatever you have written in these flows or whatever you have automated, that is ran on ServiceNow. Lastly, we have easy integration with third party applications. So people who are like dinosaurs like me who have been in ServiceNow for a very, very long term, we were actually do writing REST messages, REST scripts, SOAP, and all. So I remember all those days. But ServiceNow has introduced integration hub on top of flow designers, and then you can integrate with those tools without writing even a single line of code. And we have an example for you at the end of this webinar as well. So we will see. Next, we have important components of flow designer. So these are five components which we believe are very important for you to understand if you are getting into flow designers, if you are starting to learn flow designer, if you want to understand how they work, or if you have to automate a process, these are the essential things you should know. The first one is trigger, and this is the starting point of the flow. So when do you want to call your flow? In here, you would define it as when a new incident record is created, for example, or SLA is triggered. So if you have written SLA on your incident ticket, or maybe these flows could be ran as a schedule as well. So in here, in these triggers, you would define actually at what condition a particular flow will run. These triggers are present out of the box. You can just directly go and select which trigger you want, like, you want it on created or created or updated and so on. So we have all those conditions, which we'll take a look or a peek later. Next, on the second one, we have sub flows. And here, I would ask Selma to pitch in and explain. about sub flows. So thank you, Hadith, for the great intro of flow designer. So sub flows are the main important component where we can reuse the set of actions. So So let's say it's similar to functions. So if you're from functional background, so it's like a function if you want to reuse the same function in many more places. So we will just create it once and reuse it and plug in plain every flow. And we can even call one subflow from another subflow too. So these are very these are very handy, and these are reusable components. And this consists of a set of actions. So we are basically grouping a set of actions and recalling them whenever we want. So that's subflow. We will look into deep how we will actually go and execute it in the example in the PDA going forward. So and the third important component is actions. So these are the heart of flow designer. So these are, like, whenever you want to perform any task in ServiceNow. So we have some set of predefined out of the box actions given by ServiceNow itself. Let's say if you want to fetch some records, how do we do that via scripting? We can go and write a glide record. So in flow designer, if you want to do the same thing, we have an action available right for us without even writing code. Like, we you don't have to write glide record and all that. You just have to pick an existing action. So let's say if you want to send an approval or send an email notification. So we have lot of out of the box useful actions, and we also have a provision to write our own custom actions. Let's say, if you want to if you want to integrate if if you want to use integration, how about if you want to push your details to some external database? So these are not available out of the box for us. We can create our own custom actions and do all those customizations. Yeah. Do you want to add anything here, Hadith, for actions? think I'm good. Yep. Okay. So moving forward, error handling. So error handling is the most important step. Without this, if we move if we are moving the code to production, so that's a blender. So this this is useful. Like, let's say if you're writing 50 lines of code, and you don't know at what point of time your flow can fail. So for for example, if you are sending an email notification and the email doesn't exist in the database or there is an issue with the email ID or the sing or the email ID format is incorrect. So at that point of time, your whole flow would fail. So you would have to come back and check-in the executions where it is failing, why it is failing, and all that. So error handling comes in handy there. So for each and every flow, we have this component available. You can enable it before you move things to prod and even for testing purposes. So it tells you whenever an issue is happening anywhere in the flow, it stops the execution there. Then we can even write some actions. Let's say if there is an issue, your email is not proper proper or if your email ID is not correct. So at that point of time, the flow fails, then it goes to error handling steps. So even in error handling, you can define a set of actions. Like, what happens? Let's say now my fail is my flow has failed. So what should I do about it? So I can create an incident to an admin team or a concern team who can look into that. That oh, this flow is not executing anymore in the fraud. I have to take some action. This is what we do in error error handling, and it's a way it's a best practice to always enable error handling for every flow you write in code designer. Right. Yep. I would like to add actually something here. Why Salma is really, really excited about edit handling? Because we were both working on a project, and we went live without edit handling, and that's why she's actually emphasizing on this. And what really happened is the example which she shared, we were sending emails to some users, and that was running fine until we found there were some users who who did not had email IDs in their user account, and our flow started failing. And the problem was if you don't have error error handling, you will never know your flows are failing behind the scenes until and unless somebody goes and specifically looks into that. Also, they are not erroring out gracefully. That means it just errors out, and it's it is staying there forever. Nobody knows notices it. Even the end users are, you know, waiting, you know, what's happening with my request. Right? So error handling helps you gracefully erroring out your flow even if something unexpected happens. For example, your MID server is down or you don't have email IDs or anything randomly. Right? So that's why we have this error handling as an it's an optional component, by the way, but it's really important to have that in your flows. Next, we will talk about spokes. Like I told you, the benefits of flow designer that we can integrate with third party applications. So we have spokes, and like Selma said, we have actions. Right? Out of the box action, custom actions. So spokes are nothing, but they are a bundle of actions again. Okay? Like, she said, updating the record or creating a record. So these are also some actions which are defined by ServiceNow when you integrate with some third party app. So let's talk about Jira maybe. If you want to create a story from ServiceNow into Jira, ServiceNow provides you an action directly, which we will see. And using that action only, just drag and drop and put in the values, a Jira ticket would be raised within flow from your flow into the Jira. Similarly, if we talk about Microsoft Teams, whenever somebody wants to ping you or you want to send a message on Microsoft Teams from flow designer, that is also possible, or even on Slack. So for example, if an incident is raised and you want to send a Microsoft team Teams message to that assignee of the ticket or maybe the caller, you can do it using spokes directly. You don't have to write even a single line of code. So these are spokes which we'll show you later in, a demo. Harjit, Yeah. what you have just talked about spoke, I think, people in the chat I mean, they might have already seen lot of people who are posting on LinkedIn. Like, this post is from ServiceNow instance. Right? So I think many of, many of us have seen that. So that that is happening via spokes. So that post is being posted on LinkedIn through ServiceNow instance, so that is happening via spokes. Yeah. Yeah. I don't know if you guys are know about that trend. Please let us know in the chat here if you don't know about that trend. Actually, that trend came, I think, one year ago. Everyone post was posting on LinkedIn. I think I still see some of the people posting. that. Yeah. Right. I think yeah. Great. It was a great, I think, feature developed by the ServiceNow developers where they were posting through Microsoft Teams. So yeah. Great. I think we have a question, that, like, can we try spoke in our PDA? We will see that. Yep. And the answer is yes. Yes. Okay. So all my friends who are developers here, I think this is the moment which you are always waiting for. We will have a hands on demo now. And in here, we will discuss the same example which we discussed at the start of the event. We will initiate a request for iPhone 17. We will send the approval request to the manager for whom we are requesting this iPhone 17, and we will send a notification. And then we will allocate that iPhone 17 to the user. By the way, Salma, do you have iPhone 17? An iPhone user, by the way. I. I use a very, very unique and very, really smartphone called a Samsung Flip. So I'm not. let's order iPhone for you and upgrade you then. Okay. Alright. I'm totally in for that. Great. I will share my screen again. I'll just stop sharing it now. Give me a second, and I'll share it again. So let me know once my screen is visible. Yes. It is up. Right. So, guys, I I believe you are aware of service catalogs in ServiceNow. So we have created a catalog item for iPhone 17 in our personal developer instance. Let me know if you're not aware of that. I will give you a gist maybe later. But this is one item which we had created, and we have a variable called requested for. So this signifies for whom we are requesting this iPhone. So for example, you can request it for me or you can request it for Salma and so on, and then you place an order just like a Amazon website. So what's really happening behind the scenes is we have created this a catalog item, and we have configured a flow which will run whenever this request is submitted. Let me, go into ServiceNow and actually take you to flow designers where we had configured our flow. So here you can see I have typed workflow studio, or you can type flow designer. Either of these will take you to flow designers. So let me click here, and it will open up in a new form. And whatever you click, workflow studio or flow designer, it will ultimately take you to workflow studio. And here, you would see we have multiple options, like, can create a new playbook, which we might have a session for later on with now then. Then we have flows, which we will be creating. We have sub flows, which Selma will be talking about or which he has already talked about. So she'll talk more about that later. Then we have triggers, which I will show you, actions, data streams, decision tables. So on the right hand side, you would see all the flows which people are working on in your organization, and these are the latest updates. And here, when you click on flow, it will show you all the flows which are in your organization. So there are lots here. Okay. So there are around, like, 100 pages, I believe. So many flows are there. Everything is being automated in service, not through flows, by the way, guys. Okay. So we have created one flow called iPhone 17 flow. So I will just click here, and it will take me to that flow, or I can click on these three dots, and I can search for my flow. For example, iPhone 17, and it will bring it bring up the flow. So let me click on this, and it will open up this flow. So this is how you open an existing flow. Now if you want to create a new flow, so you are in already in flows, you can click on new and then click on flow. So this opens up in a new tab but in in the same browser. And here, you have to give your flow name. So for example, if you want to give a flow name called now then demo and give your description and application, after that, we have options for additional properties. So protection, if you want to make this flow as read only or you want to keep it editable. Then we have run as user who initiates the session or the system user. So this is very interesting. Actually, this was asked to me by one of my closest friends. So this was introduced, I I believe, I think recently, only couple of years back. So what does this mean is whenever this flow will be executed so in our example, whenever we order an iPhone and this flow is executed, should it execute as system user, that means admin user or user who initiates the session. For example, if Salma is the one who is initiating a request for iPhone 17, then this flow would run as Selma. So what difference does does that make? Right? So if you are running it by system users, that means you have the admin role while executing this flow. Run as user who initiates this session, that means it would run as Salma's role, whatever the role of Salma is in this ServiceNow instance. So if she is an ITIL user, this would be executed as ITIL user. And if there are any actions within this flow which are not allowed for ITIL, then this would error out. So you have to be very careful while choosing user who initiates this session or run as system user. This was one of the issues which we faced a lot while know. testing close. Yeah. I know. But then, you know, this thing came up when you select user who initiates the session. For example, let's take same example, actually. If Salma initiates and she's an ITL user, but we want to give additional roles while executing this flow, then you can give admin here, actually. Oh, it's not available, but you can give some specific roles, whatever are out of the box. Okay? So you can give those specific roles within this text box. Right? So I will keep it as system user, and then you can actually go and build the flow. Okay? So we have created one flow from scratch. And here on the left hand side, you would see add a trigger, which I was talking about. When do you want your flow to be triggered? So when I click on this and if people who are developers, they would know we have business rules. We have insert. We have before, after updates, and all. Right? So we have a similar, I would say, functionality here. And in here, you can choose whenever a record is created on incident or updated on incident, or maybe you can make this as a scheduled job. So you can make your flows as scheduled as well. And that you can have, run this on remote table queries or service catalogs. We will see service catalogs, in a minute. But if you choose this, for example, created, so this will ask me on which particular table the record should be created and this flow should be triggered. Okay? And in this tree after this trigger, you have to give actions. So like Selma was talking about actions, and I click on this action, it will show me some out of the box action. For example, you want to create a record in some other table. So this is one here. Or we have more actions actually, like update record, or we have, if I go here, approvals, fire event, delete record. So we have a very, very long list of actions here. Fine? After this, we have flow logic, and this is, like, in scripting only if you want to have some logic. For example, if logic else or you want to run a loop or you want to do try catch, you want to make a decision, so decision tables, and so on. So you can have those flow logics defined here. Then we have sub flows, which Selma explained a couple of minutes ago. If you want to create a reusable subflow, which will which can be called from any other flow. So we are building a flow, but you can build smaller subflows or smaller reusable functionality, and you can call those from here. And then talking about mine's and Selma's favorite error handler, you just toggle this on, and this error handler becomes active. And here you can type actions. So whenever these actions you see here, if you define here, like, 40 actions, 50 actions, and anything randomly fails, suppose the user does not have an email ID or maybe, there is some execution error on mid server, any anything random. ServiceNow has written a functionality. Any unhandled errors will go into this error handler here, and these following steps would be executed. For example, you want to create an incident here. Okay? Then we have, on the right hand side, you would see undo, redo. So for example, I have added this step or actually I have, activated this and I click on this, and it will actually take me back to the previous version. So this became inactive, or you can redo the last section. After this, you can actually, look at this flow in this view, or you can look in the other view, whatever is comfortable. Personally, what me I have seen is or I have seen other developers, are using the view which we were on, and they were not they are not using this view, which is more visual, I say, but it's I don't know. They don't like it. So we mostly used to this, actually. maybe we are used to it. Yeah. Yeah. Correct. Then you can test your flow here. You can debug your flow here, and you can activate your flow here. Once you have completed this flow and you activate it, it will actually become active in your system, and it will be triggered every time an incident is created. So I'm not activating this right now. And then we have these three dots, and we have some functionalities here, which we will talk about when we are actually into the demo. Yes. We will talk about them. add, Yeah. Harjit, what you have mentioned, so for triggers and all. Right? So one more point I would like to add is, so we have a lot of server side script actions, right, like business rules, schedule jobs. So we have all the different types of server side objects. But with flow designer, we can do we can even schedule jobs. We can even do whatever we are able to do in business tools. Right? So which one should we prefer? Right. I think this is this is for audience, actually. Let's let's hear from them. Have you guys used flow designers, and what do you prefer? Do you prefer using business rules or flow designers if you have used one? I'm not able to see the chat. So, Salma, you will have to help me out. Yeah. I think people are talking about flow designer. So I got three responses. Flow, flow. flow, Flow. flow. Yeah. Flow. Everyone is preferred. Flow designer. that's why we are into this session. And, guys, by the way, thanks for joining again this late in India. Yes. So we are preferring flow. Selma, you got your answer. Right? So everyone. prefers flow because these are easier to maintain. Then what was the problem with business rules? So you were writing a business rule for a specific functionality. Like, for example, incident is created for software. Yep. You will have five different business rules. But in flows, you can consolidate all your logic, whatever is being executed at one place, and the maintainability becomes easier, and you are actually writing almost no code. So I think that's why everyone's answer is Flow. Thank you, guys. Okay. Great. Let's go back to our iPhone 17. So we were about to actually order an iPhone for Salma, although she's not an Apple fan, but we'll anyways order her for her. So whenever this iPhone 17 is ordered, we have already created a flow for you. Okay? And I'll just give you a gist what this flow is doing. So on this flow, we have a trigger for service catalog. So whenever a service catalog request is created, this flow would be executed. Okay? And how did we define that for only this particular request, this flow would be executed? So we went into our maintain items where we had created our catalog item, and we wait. And I will just type iPhone here and quickly show you. Here, under process engines, you will give the name of your flow, iPhone 17 underscore flow. So this is the name of our flow. So by this means, ServiceNow will know whenever an iPhone 17 is ordered, we have to trigger this flow, and we have mentioned that in the triggers. Only for service catalog items, this would be triggered. And in here, we have defined for this particular catalog item only this flow would trigger. Okay. Then we in these actions, like we discussed, these are some out of the box actions which we are using. So from line number one till 11, these are all out of the box actions. So the first action which we are using is we are getting all the catalog variables from iPhone 17. So you would see we have only one variable here requested for. So we are getting that into our flow. So this is like when you are doing scripting, you are getting the variables from some place. Right? So we are getting it from catalog item. Then we are asking for approval. Now here you would see the magic of ServiceNow and flow designer By just dragging and dropping or just selecting an action as for approval, we are getting all this option that but you actually want to do it. Let me click on this edit flow. By the way, by default, it's read only. I had to click on edit flow to edit this. And here, you would define on which record this would be executed to our ATM. So you guys must be aware whenever we are raising a request for a catalog item, our ATMs are generated. So here we are asking for approval on that RITM. And here we are saying, anyone approves, but who is the approver? We are mentioning that by drag and drop. So you see here our call on the right hand side called data pills. And here on the data pills, when I expand this for I RITM record, it will show me all the fields or all the columns which are on RITM. And from here, I can actually find out for example, we have requested for here. Right? So for requested for manager, I can actually go and find here, requested for is here. And when I expand this further, it will show me all the fields under the user table because requested for is a reference field, and it's referring to user table. And I'm finding the manager for Salma in our example. And let's assume that's Hardit. Okay? And whenever, an iPhone request for Salma is raised, an approval would be sent to Hardit, and then we will check whether Hardit has approved it or not. So this is a flow logic, if you remember. So by using this flow logic, we are checking if Hardit had approved it or rejected it. So we have only one condition as of now. If Hardit has approved, we will create a catalog task for the desktop team or for the hardware team to actually assign the iPhone to Salma. And after that, we are checking, whether that task was successfully closed or whether Salma was successfully, given the iPhone or not. And once she was given the iPhone, we will send an confirmation email to Salma that an iPhone has been assigned to you, and we will close our RITM. That's it. So it's a very basic and simple flow. One interesting thing at the bottom would you would see we have error handler. And if there is any unexpected error happening in this flow, we will create an incident record. So let me click here. And here you would see we have a short description category software and assignment group as help desk. So whenever there is any unhandled error, an incident is created with this short description with the RITM number and the category as software and assignment group as help desk. I hope that makes sense. And after this, I will go and actually raise a request for system admin. Okay? I'm currently logged in as admin, and I will log a request for system admin. And I will open, actually, the user table for you as well. And let's see who is the manager for system admin in our system. And here, you would see it's ITIL user. So ITIL user is the manager of system admin, and the email ID of admin is admin@therateexample.com. So here I will go ahead and place a request for system admin for a new iPhone 17. And when I click on this order now, a new request is submitted, and the request number is this. And we will have an RITM number if I click on this. So this is the RITM number which is generated. So we are interested only in RITM number because this is where all the executions and the approvals take place. So this is the think I'll just copy here. So this is the latest request which was created, iPhone 17, for system admin. And in this r item at the bottom, you would see approval has went to ITIL user. One great thing about ServiceNow's flow designer is you can see the flow context. So what's a flow context is whenever this particular flow is running on this RITM, what's happening behind the scenes for this flow, for this RITM? We can see it in flow context. So let me click here on flow context, and we wait. It's really slow, guys. So in this flow context, you would be able to see at which step we are. So it loaded fast today, so it's a good day today. So and you would see step number was completed successfully and asked for approval. And when I click on this, I can see these are kind of logs, you can say, real time logs, what's happening. So this is not like a typical logs of your you where you would read the text, and it's in in the logs. Right? So this is kind of a visual log. So it's really, I think, great user experience for developers as well. So in this ask for approval, it would say me that an approval request has been raised for the manager here, and we are waiting for that request. And when I go back here, this request is here. As I am the admin, I will go ahead and directly approve this RITM. Okay. If we click back and come here, would see the request is approved and the new catalog task is generated. Now here we were at this step. Correct? We were waiting. When I click on this refresh, it will take me to the current state of this request. So now we are actually waiting for catalog task to be completed. So once we allocate that iPhone to the user, we should be closing this catalog task. So I have opened this catalog task, which is again at the bottom of this RITM, and here I will click on close complete. So that means iPhone was given to that user, and I will close this task. And you would see here the RITM actually is also automatically close completed when the task was completed. And if I go back to this execution, we were at the waiting state for catalog task. And when I refresh this, you would see here our flow ended at step number eight, and we were able to send an email to system admin. And the email ID, if you remember, was admin@therateexample.com, and the subject is iPhone 17 has been assigned to, and we have put in some body. Okay? So that was all happening in the flow. So if I take you back to the flow, here you would see we were sending this email. The subject was iPhone 17 has been assigned to you. The body is this and so on. So this is a very, very, I would say, easy use case and a basic use case, which should make you understand the importance of having flows in your system, in your ServiceNow. And as a developer or as an admin, why should you learn flows? I think, Harjit, we had couple of questions on the flow. Can can see, take, them later? what is Can we take we are actually running late little late. We'll. take them at the end end of the session. yep. Okay. Yep. I want to actually do one more thing with the same demo. Okay? And I want to show you the power of error handling. Let me go back here, and, you know, I will pick another user here requested for as Harjit Singh. Okay? And if I take you to the user table and take you to this Harjit Singh here, you would see this user, Harjit Singh, does not have an email ID. So it's empty. So let me raise a request for Harjit Singh, and I'll click on order now. And I will go back to the RITM, which was raised. I think it's 23. Yep. Right? So this 23 is raised now, and it has been sent to approval to system admin because the manager is system admin of Hardat. And I will approve this on behalf of system admin. Actually, I'm the admin, so I am approving it. And you would see a catalog task would be created, and here it is. And I will click on flow context also. Okay? So let me click on flow context. So we will see what's going behind the scenes and what I actually want to show you an interesting thing. So this we are waiting for this flow context, and I will actually now close complete this task. That means iPhone 17 was allocated to Harjit Singh, and I will close this task. And I will refresh this. And you would see here completed an error caught on send email. Can you guys guess why did we get this error? Any Selma, anything in the chat? Yes. Email ID is blank. Email ID is blank. Now you would see here completed. It shows us completed an error code. That means we errored out gracefully, and at the end, error handler was triggered. Okay. You see this as completed. In our earlier flow context, if we go at the bottom, this was never this never ran because our flow was executed and completed, and the flow was ended as the sup it was supposed to end. But in this case, we actually raised an incident, and the incident number is for ending with 49. And you would see the short description is an unexpected error happened on iPhone 17 flow, and this is the RITM number on which it happened. So we have specified for the help desk team that, you know, this is the short description, this is the category is soft category software, and this is the short description. So an incident is assigned to them, and they will know there is some issue with the flow or there is some issue with the data. That's why this incident was raised. I hope now you would know me and Selma. quickly open that incident, Yes. Harjit, just to doesn't trust. me. Okay. No. Okay. Let's open this incident. And here you would see this is the incident, and this is the RIT number on which the problem came. And, guys, you know, this is a task for you. Can you just remember this incident number, which is ending with 49? And I will ask you at the end of the demo at the end of this session, and I will show you what really happened. Okay? So this is a task. Just remember this 49 number. Okay. Here, Selma, you were saying something. Yes. No. I mean, I'm good. I just wanted to show the incident with the. description details populated. Right. So this is how it's created. Great. I will actually now go ahead and share my screen again, and we will move into the advanced concepts. So I will share again, And I will ask Selma to take over this now. So we'll be talking about flow debugging and integration hub. So. over to you, Selma. Yep. So flow debugging is a recent ad which happened in Yokohama release. So earlier, whenever we had I I think, think, had it had already shown us how the execution works. Right? Let's say if you have now we have created a flow, flow is running, but you want to see how the flow is running in the background. So one way to do was through flow executions. But through flow executions, we did not had an opportunity to go and stop the flow and check the live updates. So the flow executions will show you the view once the flow has been executed completely. It's not like you can't stop, in the middle of the flow and check what has been done so far. So this was, I think this was one of my favorite features from Yokohama release. So through flow debugging, developers can actually debug, analyze the flow set real time. When I say real time so let's say if you have 10 actions, you can actually put a breakpoint at step one, step five. Multiple breakpoints you can keep and see what is going on behind the scenes. So let's say if you have, like, nested loops. Right? So you don't have to you don't have the provision to check-in flow executions how actually that runs. But with flow debugger and with these breakpoints, it is very easy to debug when we are using complex scripts, even nested loops, and live variable analysis, like how the variable value has been changed after each and every steps. And, also, one more very useful advantage with flow debugging is, let's say, if you are using sub flows and custom actions, you can actually within the same flow debugger, you can actually go and check into your sub flows too. Like, you can you can debug in your sub flows too where your sub flow is failing, or if you want to add additional breakpoints in the sub flows or any custom actions, we can do that as well. So I would like to quickly share my screen and show you how that low debugging works. Let me quickly share my screen. Give me a second. Okay. So, Harjit, I'll be taking over your screen. Okay. Sure. Yeah. Yep. So thank you. Okay. So let me know once my screen is up. Okay. So now I'm in this catalog item. Let me place a new request. Okay. And yeah. So this is my RITM. I'll go back to the flow. So this is our flow. In flow designer, if you see this drop down under the test. The test, we know how like, if you want to test it, it would again take you to the flow execution screen. But But with debug. Right? So I'll just just have to there's a drop down under the test. I'll click on debug. And in the debug, it would ask you what which r a t m record do you want to debug. So I've just submitted a new request. So I'll just use the same one here, and I'll click on debug. Yes. So now if you see the screen, this is a debug mode. So if you see, this is our debug mode. And on the left hand side, for each of the steps, right, like, is step one, two, three, four, we have multiple steps, we can add a breakpoint here. We can add multiple breakpoints. Add here. It may add here. So I've added three breakpoints. So what this does is it would exactly show so I have now I have added breakpoints. So let's go and click on this resume. What we have few buttons here. Let me quickly take you through what these buttons does. So when I click on resume, it hits all the breakpoints. Let's say we have three breakpoints. As soon as I click on resume, it hits near the first breakpoint. It means the flow is stopped here. The execution of the flow is stopped here in the ask for approval action. But before this, we have this get catalog variables. You can go through and check what is happening here. So let's say if you are setting some variables or if you are getting values from some tables, you can check here before this what is happening. So now we are here. So let me click on resume again. So when I click on resume again, so it goes through the flow, and it's the another breakpoint. So right now, it is in waiting state because it's an approval action. Let me go and go back to the rhythm, r a t m, and approve the request. Let's refresh it. Yeah. If quickly go okay. Now we have here two approvers. So why is that? Because already I have submitted a request to portal. Again, when I'm debugging it, it would actually go and execute the whole flow again. That's So where we are able to see two of the request approvals. Let me approve both of them. Okay. Now I'll go back to our debug mode. So as soon as I approved it, now it is telling that it has been evaluated true, and it's now waiting in the catalog task state. So if I go back again here, I'll just refresh this. So we have two catalog tasks. Let me complete them. I'll come back here. I'll come back here. Now it is hitting this. So it's in the debugging mode. Again, it is checking. If the state of the catalog task is test, close, complete, then send email. So it's stopping here. Why? Why? Because we have a breakpoint here. So let's say if you did not have breakpoint, it would go and execute it. So when, again, when I click on resume, what happens? Can anyone guess? It would again go and stop where the next breakpoint is. So now I'll explore a few other options here. I hope you have got to know what resume does. Resume goes to every break point which we have applied, and it'll stop the execution there. That's what resume does. But what does step over does is step over actually goes through every other step even if there is no break point. Let's say if I'll just click on resume. Okay. I have clicked on resume, and it executed this send email, and it stopped here. So now if I click on resume again, it would actually end the flow because there are no more break points here. But if I do step over, it would actually go into the next step, which is there. So after the send email, even though if you don't have any breakpoint here, we can actually go into each and every step. So here, we have seen, okay, the send email, it has been successful. Now it is here. So I can actually go and step over and check each of the steps. So that's the difference between resume and step over. I hope that is clear. And there is one more very important action here, which is called a step into. So this step into is very useful when we are actually using sub flows. Let's say if there is a sub flow here, when you are going into step into, it actually takes us into the sub flow the way you are seeing the debug mode execution here, the same way we can see the subflow execution here. So that's step into. And step out means it would get us out of the subflow, and we have one more option, skip all breakpoints. If you want to skip all the breakpoints, you can skip it, and it'll go to the end. So that that's how handy this debug mode comes in. And I hope you are clear the difference between the actual flow execution and the debug mode. Debug mode is giving us the opportunity to stop the execution at any point of time. Let's say if you are having a lot of loops here. So you can go through each of the iteration and actually check for each iteration what your value will will be. I in normal flow executions, you don't have such option. So this this was a great addition for me. So, Harjit, what do you say? How how did you find this feature? I think, yeah, before this, we were always struggling to. find the exact execution and what was happening behind the scene. I think after this, ServiceNow listened to us, and we were able to do a lot of things here. Yeah. So, So I just. wanted to cover one more really Yep. So, Very very important important feature. right. So I think yeah. Yeah. Please go ahead. Sorry. Yeah. Yeah. So this was very handy for me. So I'll just quickly share it. So if you go on to this history, right, on the right corner here in the middle, so we have this history button. So, earlier, whenever we used to change anything in the flow and execute it, and if you want to go back to the previous versions, like, we did not have that provision. So in Zurich, in this Zurich release, they have added this. This is an absolute game changer for me because whenever I worked on Flow, I wanted to go back to previous versions. So with undo and redo, we can go only for one version back. But with all these, you can have a history from the beginning where it was created, and you can actually fill it'll just select a fifth March version of this. I can go to fifth March version of this flow. Only these these three were there at that point of time. I and I can save a copy. So you can create a new flow with a copy of that particular version. It was very handy for me, so just wanted to do this. This this is one of the new features of Zurich release. Sorry. Okay. Go ahead, Harjit. I'll just stop sharing. you, Sama. Yeah. So, Adi, you know, just before Simon starts scolding us, I will give show one more thing. We were we are actually short on time. We have only two minutes left. So I just wanted to tell you about integration hub. I'll not share the slide. So integration hub is a plug in or you could say up an application provided by ServiceNow where you can actually install the spokes which we earlier talked about. So we have, for example, a Jira spoke which I have activated on my ServiceNow instance. And, you know, what I did is I created a flow, so create issue from incident. So what this this do is whenever a new incident is created and the table, we will select as incident and we have given the condition as category software, a new issue should be created on Jira. So I have already set up this integration behind the scenes, and I have already set up a sample project in Jira. And type of issue which I'm creating on Jira is incident, and I'm giving the summary and description here, which is the actual short description of the incident, and the description is description of the incident. So, guys, do you remember we unexpected incident was raised here. Right? And the category was software, if you remember. Right? So when I went into Jira. Right? So this in the in the Jira, what the integration hub from integration hub, I have set up this integration, and you would see this was created. And when I click on this, you would see this r I t m number here, and this was the r I t m number on which the error came up. So we are actually short on time. I'm so sorry, but we will discuss it in the next session, definitely. And I will show you step by step how we did this. But I think I'm good as of now, Simon. And sorry for taking up that much time, guys. No worries at all. And I'm sorry that we didn't have any time to cover the questions, but I think that Hardy went through and answered a lot of them by text. So you should hopefully see your answers to some of the questions there. Amazing. I'm pleased that people have enjoyed the session. But, yeah, thank you all for joining us today, and thank you, Hardy and Salma, for taking the time to take everyone through that as well. As I mentioned in my intro, I will be sharing a follow-up email, which will include the recording and also the slide deck as well. And, hopefully, if Hardy and Selma are happy for me to do so, then I can maybe share their LinkedIn as well so you can continue the conversation on there as well. Yes, please. Fantastic. Thank you all for joining us, much. and, hopefully, see you in our next webinar. Thank you, guys. Thanks, everyone. Bye bye.