hey everyone welcome to another go with the flow my name is Robert fedorik it is so good to have you here in this episode we are going to cover a really basic flow designer concept which is the creation of sequential tasks rather than tasks that run in parallel to demonstrate this I'm imagining a scenario where I want incident tasks added to an incident sequentially so I've already gone ahead and created a workflow in this flow the first thing we're going to do is create a task that task is going to have a short description of task a and we're going to relate it back to the parent incident next we're going to ask if task a is in closed skip State and if so we are going to create another incident task called task B also when task a is finished we are going to create tasks called task C and once task C is complete we're going to put work notes in the original Parent incident that says that all of our subtasks are complete all right let's give it a test hit the test button we've got an incident already that I wanted to use and let's run the test let's view the test results and even though the test says it's completed we can see that there is a lot of stuff that's gone wrong [Music] first of all it's gone ahead and completed the action of create task a that's what we expected it then evaluated the if statement which is not what we expected because we wanted to wait for task a to complete then it went ahead and completed the creation of task C again not what we wanted we wanted to wait for the completion of task a and then it's gone ahead and updated the incident record which again we did not want because we wanted that to wait until task C was done now if we go to the actual incident we can see that the worknote says all incident tasks has been completed and if we go to the incident tasks tab we can see that both task A and C are there and task B isn't there because obviously task a wasn't closed skipped so what went wrong so I intentionally plan this workflow to fail so that you could understand the exact thing you got to pay attention to when you're trying to create sequential tasks it's a simple but profound checkbox that even I have forgotten about times and the check box is wait wait forces the flow to wait until the task is done before it proceeds to the next node in your workflow so you'll notice that task a didn't have a weight that means that as soon as task a was done creating it then went through the if statement and because tasuke was created as an open state that means that our conditions of Task 1 State having to be closed skipped could not possibly manifest therefore task B couldn't get created and also task C could be created because it's not waiting on task a to get done and then of course because task C has no weight you can go ahead and update the incident record so because we didn't put weights on each of the tasks that we need to wait for that means it all happened instantaneously okay so let's get out of this failed flow and go to a flow that actually works so this is the add incident tasks no wait we are going to go to the ad and tasks and let's take an inspection here let's go to create task task a and we can see that it Demands a weight that means that node 2 if task a skip tree task B can't proceed until task a is finished likewise we're going to go to task C and we're going to see that it has a weight as well and that means that our update incident record action can't possibly work until task C is completed let's test this one out so we're going to test I've got a specific incident I want to test this against run the test view the execution details and this test tells us that we're waiting it means the flow hasn't got to complete why isn't it Complete because it's still waiting on a bunch of stuff so we can see through the log that task a has run but it's still waiting let's go to the incident and actually see that in action here we are on the incident let's go down to the incident tasks and we see this task is here it's task a and its state is open let's take this incident task and put it in a state of closed skipped State closed skipped save now we go back to our flow designer and let's refresh this test flow so now Tasca is registered as completed and that means our evaluation could happen it evaluate is true because task a was set and closed skipped and then it's gone ahead and created task B it's also gone ahead and created task C but task C is waiting so we're back on our incident we see both task B and C are still open let's go ahead and close those those complete save let's go back to our flow and see what's happening we're going to refresh and the create task C has been completed and also the update record has been completed so we should go back to our incidents and we now see that all incident tasks completed has been added to the work notes and there you have it folks a simple weight switch on the create task action in flow designer can mean the difference between a bunch of things running in parallel and a bunch of things running in sequence [Applause] one thing I didn't get to demonstrate that I also think is super cool is the fact that you can use code to determine whether you're going to wait or not you'll notice that when you're looking at this weight field there is this toggle scripting for weight in which you can use script to determine if the weight is going to be true or false so even more nuance and capability there hope this one was useful for you and I will see you on the next one hi my name is Robert the Duke fedoric I am the servicenow consiglieri I do freelance architecture and development on servicenow I also do recruiting and individual and group coaching if you need better servicenow outcomes you can reach me at Rob the duke.digital I can't wait to hear from you