welcome everyone my name is lisa howenstein this is our 19th platform academy and today we'll be going through some flow designer performance and debugging tips it's so awesome to see all of you uh joining us there are a bunch of people that i recognize who have joined us before if you have any questions during the session please put them put them in the q a panel or just ask them and chat as i said my name is lisa i'm an outbound product manager for workflow automation i live in germany i've been working with the now platform for over six years now and i've been with servicenow for about three and a half and i'm today i am joined by my wonderful colleague that is andrew barnes please give a quick introduction to yourself absolutely happy day to you lisa i'm andrew barnes i'm a product success manager here at servicenow specializing in uh creator workflows so things like app engine studio and uh i've been on the platform for a little oh gosh eight eight years now i think it is something like that i don't know it's amazing maybe more than that knowledge 14 feels like it was uh a long time ago was my first one uh and i'm i'm excited to join you today and talking about one of my favorite things again which is slow designer hello designer i love flow designer i'm not sure we're actually going to be talking about any forward-looking things today but just in case here's our safe harbor notice so don't make any purchasing decisions made on any uh anything that we say today um our agenda today is a little lighter than usual but i hope we'll still get a good conversation going once we've taken you through some of the performance and debugging tips we've already had two different flow designer sessions on this academy the first one was back in april or march about flow designer good and best practices and the other one was just two weeks ago about um flow designer my brain just left me help me andrew i was scared i don't even remember what were you talking about uh i i i don't know i'm drawing a blank it was academy 18 and we talked about floaties lighter and we was migrating yes migration yes it was it was it was uh you know how to use uh flow in place of uh other processes like the old workflow editor and business rules and scheduled jobs and yes inbound actions all of those things all of the good migration use cases so for those of you who have missed our past sessions on flow designer i've faced the links in the chat i'll also include them in the resources and the presentation when i share this after the session and on youtube so if you're interested to learn more about those topics and haven't seen those yet please feel free feel free to check out the recording on youtube leave us likes and comments and feedback and everything that you want to know about it so in addition to the performance and debugging tips i have also prepared a small live demo today and we'll go through some of the features that we'll be talking about so you can i can show them to you in a real instance and with that out of the way and also thank you eric for jumping our brains about the topic so we'll get started with some performance guidelines um and tips to how to avoid performance drains in flow designer if you have completed the cretacon lab 1069 during knowledge which is best practices for building with flow designer and integration hub most of these recommendations will feel familiar to you but if you haven't i want to encourage you to absolutely check it out it's available on demand on now learning and if you're signed up for digital knowledge i think you can find it there and go through the lab and do it in an instance that gets that you get provisioned through now learning and um you can get and it's hands-on right yeah exactly so it's a hands-on lab so we'll be talking through you know some of the guidelines that are found in there and the hands-on lab actually like takes you through it and gives you some of that muscle memory of thinking through it and doing it at the same time yes yes eric eric says it's a great lab i learned a lot absolutely i think it's an amazing lab there are so many great tips in there um more best practices some guidance also how to get started using decisions um so definitely check out this lab and the others that are in the resources so the first thing we want to talk to talk about today are reporting levels um so the reporting level determines uh what if any information is saved in the flow execution details if a flow runs while reporting is off execution details are never available for the flow even if the reporting level changes if a flow runs while reporting is activated execution details are always available for that flow execution even if the reporting level changes again so the reporting level has no effect on context and log records too our recommendation is to keep reporting off in your production instances except for key flows that you need to monitor for a specific time in non-production instances you can for example activate the full reporting which would be flow and action in step and it is very valuable for debugging and testing can we turn on the reporting i'm i'm guessing is the question lisa asks can we turn on um the reporting for specific flow and the answer is yes um i will show this uh this setting later in this session and we're actually working on a feature to make it easily accessible from the flow directly in the next three you see there's a future looking statement they always sneak in yes it didn't take very long but yes um so you can globally turn the reporting on or off or have different variations for it um you can turn it off turn it on only for flows um for flows and actions flows actions and step steps and then for very detailed debugging you can um set it to developer trace reporting um you can activated for specific flows and i'll show that later um the next uh slide that i'm going to walk you through are some general guidance and tips to follow when working with flow designer to make sure that your flows stay performant especially when your flows get more complex or longer consider creating subflows if a flow gets longer than say 25 actions another recommendation that i should have put on this slide but haven't is if your if your process is really complex consider using process automation designer you'll have granular granular subflows each of the subflows power and activity that is a step in your process and you can have those run in parallel after each other or dependent on other conditions um so the guidance that we give you here is that flows should be short modulo modular and reusable collections of work if they're taking more than an hour to execute they're probably too long and you should consider refactoring that that's that's a good call out especially the one uh when i've seen several folks try and cram everything for their process into a singular flow uh and in with using a bunch of subflows and things and it can be done but we have a tool that's built for that purpose which is process automation designer and so you should look at leveraging that and the outcome there that is you know an extra added benefit is then you get the ability to leverage playbooks which makes the experience for the you know the people working through that process even better and um this is a perfect uh place to call out our next academy sessions because our next academy session i should have looked up the date i think it's july the 4th which is a holiday i guess in the us but we'll still go with it so uh in the first week of july we'll have a session about process automation designer on this academy we'll be joined by jason lefevre who's the inbound product manager for this uh product and then uh we'll take a small break for the summer and return on um august or maybe it's july 7th and august 4th that would i think that those are the dates we'll put them uh put the post in the uh resources as well the second session will be covering playbook experience again we're being joined by jason the fever so if you haven't um learned about those products yet please join us they're really awesome so one question about the you mentioned the the long-running flows so you know if a flow is executing for more than an hour you should consider looking at refactoring it yes because because that's a too long of a running and executing flow um and eric asks the question about uh well what if a flow is waiting and that's a different scenario so i wouldn't call that flow uh executing at that time it's it's waiting so uh one note on waiting though is i don't like to have uh as for example uh something that's waiting for a really long time so if you've got a flow that's waiting around for something that's more than a quarter out uh it's probably not the right way to to design the flow yeah in in those cases i would go ahead and just end your previous logic at that point when whatever record is created and you're waiting for a specific condition create a second flow that either triggers of that condition being true so if you have an incident and you're waiting for it coming off of on hold for example it's just the example that just popped into my mind so you would have a different flow that triggers off of the state changing away from on hold to a different state or say back to in progress and then a new flow would run and do further logic from there so this could be something the other option that you have is making use of scheduled flows that run for example every friday or every other week and then look up records in a certain table with a specific condition set and then for those records run the logic that need to run if the conditions are fulfilled awesome tips yes so uh speaking of when flows run and how they run we do have some documentation on our docs page that gives you the execution order of scripts and engines so a lot of people say well our main we have a problem with flows being queued and and when do they run it's really hard to say so check out that link when i share the presentation it'll give you a specific rundown what engines run before the database action is being complete and then after and specifically most flows run in the after or async context so if you configure the flow to run in the background they will be queued they run just like async business rules if you set them to run in the foreground that is synchronously and they run in the after context i want to recommend for you to use conditions like use them very carefully so set conditions appropriately limit pulling large numbers of records uh by applying conditions first so that you only pull a smaller set of records this will ease the load on your database so don't create a flow that says trigger from offload all incidents that change to something maybe add another uh another condition that suits your your use case maybe there's a category condition or an assignment group condition or priority group conditions so if you're doing lookup records or even for the trigger conditions of your flows apply conditions as much as possible so that you don't query the whole database and then the second one would also apply to scheduled flows for example um when you run the schedule flow make sure you have the right conditions when you do the lookup records and then the second recommendation here is to use the trigger conditions so that the run flows only run when required rather than triggering them and then immediately adding a weight for a condition we don't we don't want too many flows that have the weight for condition idling around and similarly um this recommendation of course also applies to for each logic so only iterate through those records that you actually need to be um applying logic for based on the conditions all right that makes so much sense i know it does when you think about it but when you're when you're in the in the weeds you don't always remember okay um one really cool thing and we've uh briefly touched upon this um last time two weeks ago uh there is a quick api so whenever you're you're required to call or trigger your flow from a script there's an option to add a command that it runs in the quick context and that means using those quick apis for weekly starting executions for example as business rule replacements quick api executions are faster not specifically in the execution because um but but they run quicker they don't have any execution details so there's a lot less debugging capability here and it does not support wait for conditions approvals wait for duration or any mid server execution they will always run a system too so rules or user contacts does not apply to the quick api then i think that's good to know so for example if you want to just quickly update some fields based on some other input that is getting saved you could use that and use the quick api in a ui action and with that ui action um call the quick api update the fields and there's not much need for execution details for those quick interactions that that makes a lot of sense to me so so when is a scenario in which i would be calling a flow via scripting that i wouldn't want to execute the quick api and so right off the top of my head is one is if i don't need it to be quick like if i'm not uh trying to return the user back to their interaction uh fast that would be you know if it can be asynchronous let it be asynchronous yes or if it uh you know if i have a case where i need one of those things that quick api doesn't support well then that will definitely be a time that you would like to uh you know not use the quick api because it's not supported for those use cases yes um but i'm trying to come up with a you know if i was making a decision like would i lean towards quick api or away from it um on an average case decision yeah i think a good a good rule of thumb is the the recommendation that we see in in point five here and that is whenever you can run your flows in the background so execute them in the background to release the ui threads so if you don't need your user to to actually act on that data right away i would i would recommend to release those ui threads and don't have your users waiting for flu flow executions i think that's the best uh the best rule of thumb so if you need it if you really really need it and the user needs it to proceed go ahead run it in the foreground and use the quick api for example if you don't need it if it's not necessary it's better to to have things run in the in an orderly fashion well that seems reasonable yes default towards asynchronous and running in the background to release it unless you absolutely need that scenario yeah and then the other recommendation here is never you to use a gs sleep in your scripts for that i must confess i don't even know what that is but uh jake told me this is important so i put it down it just makes it wake so obviously just holds your your thread and your execution and it just waits okay so well we don't want that sitting there uh it's active it's executing uh it's just waiting for time there are some use cases in which it makes sense to wait for something but in these scenarios we we certainly want to avoid it in your complex scripting scenarios where you need to to you're invoking something and you need to keep your execution going um but you have to wait for that other thing to to come back to you you know so run conditions you know those race conditions will sometimes get you and you'll have to do something dirty like inserting asleep but we like to avoid that okay well then let's keep it with that in the flow context don't use it all right another tip that i have here is uh it's a good idea to refactor this to use a wait for duration or wait for condition because this allows the thread to be released and it can perform other necessary work and this also helps to in to avoid a lot collecting large a large output and then immediately quieting quiesing that is an interesting word i don't know it i think it's uh this is about the sleeve so we don't want to collect the large output of data and then just put it to sleep and not use it that doesn't make a lot of sense so instead make you make use of a large payload immediately after it's retrieved so we don't want to keep the large payloads in the in memory working memory we only want to keep it as short as possible for as short a time as possible and then the last point here is we want to minimize environment switching so avoid interleaving instance only or mid only steps so um don't don't go back and forth all right that that's just uh that's that's good integration tip anyway is [Laughter] try not to switch back and forth between the two systems uh too fast and too often yes next tips we have a couple of shorter ones but equally important for flows that have nested looping there's a system property that we recommend to consider setting to 1 and this way the reporting is on [Music] is when reporting is on the previous loop iterations don't consume too large amounts of memory we'll also recommend you to not build parallel branches that depend on each other so if you're running things in parallel they should be separate things that can run in parallel and don't interact with each other going on for loops so when you create loops especially if you're working with scripting inside actions or script inline scripting please don't put too complex scripts in your inline scripts if they get too complex put them in custom actions but when you are looping avoid loops without valid exit conditions so ensure that there's a loop counter and there's scope by adding a var and remember that scripting loops in actions or inline scripts do not heed the property for max iterations in flow designers so it's not capped by that property and make sure that your loops have have valid exit conditions i think that is a good recommendation for any loops in anything in general yes just in general but even more specifically here and similarly avoid to do any for each or do until loops that have over a thousand iterations for larger amounts of data processing consider batching them into smaller batches and similarly for bulk imports consider concurrent imports or data stream actions that use pagination so that you don't process too much data at the same time again don't put heaps and bounds of data in your working memory because that'll not do do well and those were the performance tips those are some good performance tips um the i just want to replug the the lab again um so that uh because for example um one of the the tips that you said there lisa was talking about uh you know using the the quick api and um operating with the the different logging levels on and it actually walks you through and shows you and measures the difference in performance oh yeah um and and lets you see that in those labs and so that's that's nice to see for yourself not just be told this operates faster but actually going and running it and comparing it yourself uh sort of blocks that in uh in at least in my memory is when i go do it and i look at the performance change myself and measure it myself it makes a bigger impact in uh you know moving it up the hierarchy in my brain of things i should remember yeah that's how your brain works it's if you if you've done it yourself and you've seen the numbers and the milliseconds that the flow is running and how how how long it takes to complete it'll stay with you and then you'll uh heat those tips all right let's get into debugging um the prior to rome catching errors in flow designer was a little hard because you'd have to work with um subflows and figure out what how to handle those if the the subflow or any action in the subflow would run into an error in rome we introduced our first version of error handling and we have error handling on two levels once uh one is on the flow level and the other is on the action handle so action layer so in in action designer um both allow you to identify um errors that happen in any of the steps um during the execution and the cool thing about this it'll allow you to handle those errors and um to for example make sure that your your flow can continue running um so one of the things that we've improved in san diego and i'll have another slide coming later is that you can use the try logic so if you have a try logic and you have defined your error handling to to catch those errors your flow can just continue if you want to even if an error has happened a flow usually stops running when an action or subflow returns an error in the main section so a stop flow cannot run any actions or subflows past the point where it returned an error adding error handling actions and subflows to the error handler section ensures that that they run them when there is an error so say for example something in your flow goes wrong and you have an x extra set a section where you can tell it to maybe send a notification to the developer or the owner of an integration or um try a remediation step and then trigger the same flow again from from this error handling session additionally this allows you to capture error status information so this object contains information about the action that produced an error and you can also use this uh information to identify the co the cost of the error as well as recorded data that may need uh correction additionally you can suppress subflow error messages so you can enable the error handler for subflow to prevent its errors to be cascading to a parent flow so leaving the subflow error handler section empty ensures that it always generates the completed in brackets error caught state additionally if you use subflows in the error handling area this helps you to avoid the 10 item limit so if you want to have a more complex error handling logic you can call a subflow from there and that can contain many more items you can also use the subflow to trigger automation in another flow and using the subflow there in your error handling makes a lot of sense because what are subflows those are the repeatable uh you know objects and therefore i can have some similar error handling across a lot of different flows and instead of you know injecting those directly individually and configuring them all i can use that sub flow or a couple of generic subflows that are are my different use cases for error handling so flows make a ton of sense oh yeah in the error handling area for me subflows are really really good i like them a lot so we can use subflows to take corrective actions too so rather than recreating the same sequence of actions in multiple flows and you just correctly pointed out we can create reusable subflows to correct errors in your recorded record data so when a flow errors your lead when a flow error leaves your record data data in an undesired state use the subflows to correct those records and you can use the error handler to identify such record data as a subflow output for error handling and actions um it allows you to um allow only independent steps to continue running so if it does not return the data required by the later step and then if the step provides data necessary for later steps then you know that the later steps cannot run successfully avoid to have more than 10 error conditions while there is no limit on the number of error conditions you can create each error condition requires evaluation so the more error conditions your action has to evaluate the potent potentially slower your action can run identify specific step failures so you can use the step status to identify when a specific step fails identifying a specific step can be useful when your action contains multiple instances of the same type of step and you might also want to identify a specific step so that the flow error handler can take specific corrective actions for the failure additionally you can also put specific error conditions before or you should put specific error conditions before general error conditions so the error error evaluation stops as soon as the action finds a matching error condition so putting general error conditions first may prevent the action to ever matching the specific ones and you can drag and drop to reorder them so if you added a more specific one later you can still uh drag it up the order and it it will then run earlier and then the last point here is use descriptive error condition labels uh by default you can only see error conditions uh when you edit them so a distrib descriptive label allows you to identify an error condition without having to edit it so these are some some really good tips around action error handling we'll see examples in an instant in in just a minute but before we go further something that i've already talked about earlier we added in the san diego release you can now run use the try logic to attempt a series of actions or logic and then continue with with the flow even if that section runs into an error so this is like your try catch and scripting and you can even put multiple tries in like cascade them and have different ones and then try multiple things before you return to your main branch but even if something runs into an error an action runs into an error you can still return and execute the rest of the logic so try logic we've talked about try logic it's amazing i'll show it in the demo in a bit and then the last part is what do you do when things go wrong uh so your first step would be if you have execution details check those out if you don't review the logs in the related list of the sysflow context record all flow engine errors should be captured there so even if a logging if the execution details are being turned off the logging is still there and locks from elsewhere are also controlled by a specific property so definitely check that one out you can set it to warn or info temporarily while you troubleshoot and then revert it back you can also and that that fits one of the questions we had earlier you can also enable the flow reporting on a per flow basis and review the flow execution date details specifically when you test a flow from flow designer so you hit the test button to to test it out manually it'll always create those execution details even if flow logging is a reporting is turned off and then similar to the the regular flow reporting we recommend that you only turn on the fl the reporting on peripheral basis um temporarily so that you don't consume the resources when um all of those execution details get generated so that was all i had here and now i'll go and switch away from my presentation and give you a small demo and show you some of those things that we've talked about so um this page that i am on right here is the flow properties you can get to it by navigating to process automation flow administration and then the properties and this is how you get to this list and i want to highlight the two properties that i've talked about earlier and one is the specific log level for system log entries that are replicated to this flow log and it's as it's default to error but you can set this higher if you want to for um in either in your dev instance or for a short amount of time to to figure things out and the second property is the level of reporting data are generated those are the execution details that you can see also see when you test um your flows and the other some of the other properties have been mentioned in the slides also i've talked about log levels earlier when showing different flow properties i'll show the specific example in this subflow i have a log action that is currently set to info while the property is on its default error when i test my subflow and check the flow log record there is no log entry here i'll change the log level of my action to error save and test again this time you'll see the log message in the flow context record as well the second feature i've mentioned previously is to configure the reporting details level on a per flow basis this happens in the settings page you can create a new entry for your flow and choose the relevant level here in my example i'll pick a specific subflow and set the reporting level to developer trees and save so for our flows i've created a couple of examples so i've created a couple of actions some of them i love examples yes some of them run into an error and some of them don't so in this one case this one will just call our regular flow api i just wanted to show a step that has will run into an error in this case it doesn't have a credential alias so i'm just to show you what happens i run this test i run this um this action and this is not handled at all so there's no error handling happening in this action and it will fail out with an error and we get a very not useful error message so this doesn't help us identify the problem at all right we have to go in here and click on the steps and then figure out that oh what what's happening what's going on oh we're not unsyndicated so it takes a while it it leads you on it leads you down a false path because it tells you that json parser operation failed but the actual error is that the status code is 401 and that we have an invalid username and password combo because we didn't give it any credentials and that happens so often right is you get an error because you're expecting some data and you didn't receive it yes the step or action that is erroring isn't actually the one that had the problem yes it was it was the thing that was feeding that the data i didn't feed it the right data correct happens all the time my second example is a copy of the first action however this time i added an error evaluation so i added two of them just to be safe i added the if the json parser failed then give me some some data pill error messages from my step in this case it's the json parser step codes that i want to output but before we go there we figure out that we want to see that if my rest step doesn't run successfully in this case the status code is 401 then i also want to output the 401 and the invalid username password combo so this time when i run my action and i see the execution details i will find that it shows me in the action status so it will still show me the arrow up here but the actual output so if this is in my subflow the output tells me this is a 401 invalid username password combo so now i know what's happening and now i can work with that the that's a that's a lot more clear it is so just to show you what happens if this is another copy this time i have um i have credentials so this time we should just get a regular output and get our data and no error so just to be safe and show you this this can't work if you provided the correct info all right so this is how error handling works in actions we now uh want to look at how this works in flows and to show you this i have a couple of subflows and the first example is i will call the aronius action that will definitely run into an error and the error message is not helpful so let's just run this real quick luckily they're not very long and what i want to show you here is that when we run into the error first we get a not helpful error message and second my log action does not run so we don't even like it doesn't continue nothing happens after so to handle this um i can now run my handled my my action with the error that is handled my subflow does not continue here but i can add a hair an arrow handler to my subflow through for example lock some remediation actions assign outputs to my subflow or run another subflow as a remediation so when i test this this time we have caught the error so my action is completed the error is caught it gives me a useful error message in my action status so we don't have to dive into the steps to find out what happened and because my action ran into an error that was caught we will jump into the error handler section so now my other log will run and i can run assign subflow outputs and the subflow will also run so the um the output can be seen up here because i have mapped um [Music] the the subflow output here output data all right so this is this is cool if you have uh error handling in your subflow the next example is using the try logic that we've talked about so the idea here is that we have an um an action that runs into an error and will log the message if it runs into an error but we'll also want another lookup happen later so it's not just the the action we don't want our flow to stop with the erroneous action we want to continue down the path and this is what you can do with the tri logic as you can see here it tries to run the uh the action it has an error it does not jump into the error handler but it completes it locks something and then the next step also runs and we get an output from there so this is the big benefit of the tri-logic that is added in the san diego release that yes i think so too and the last one is a little advanced so what i've added here is not just a try but also a do until so you can imagine if you are running say a subflow that has remediation actions in the error handling and you want to do those steps until it works so maybe your rest api that you're calling is just not responsive right now and maybe it'll be responsive the next time you try 10 seconds later so you can combine the power of do the following until with the try to try a couple of times until it works so this is what this flow does we will try it in this case we're using the api that has no error because we want to show what it looks like if it does work it'll only run through the try the do the following until once and it will check it will work and we will check on the code and then set some flow variables and the flow variable is the condition to leave the do until loop and then we'll look up records nice nice now uh from your from your powerpoint of your uh you know suggestions i i'm now going to ask you said that this is a do until uh do you have a way to exit out of this you have to you have the condition here um to to exit out of this so there's an uh there's an option to add a manual condition here but i believe there's a number of iterations on the roadmap so you can tell this in in the future you can tell this thing to try 10 times and then uh abort it's it's in the i i think it's in the improvement roadmap okay yes i know i was being uh sneaky there but uh um one other thing to note specifically just because we're uh you know your example uh involved you know connecting to a an api that may not be there there is a separate older um you know use case that's already handled uh for those in the action itself to be able to to do retries for those new steps absolutely let's show them they're here that retry policy is where you should go first if you're trying to handle the use case in which uh an api may not be available yes um at that time so start with the retry pro policy yes that is a very good call out the um the main idea that i had for retrying the rest is if for example your token has expired and you need to refresh your token first you can have the refresh of the token run in the remediation actions and then try again well absolutely that's a great use case right so this much for um the live demo let me check if i have some more slides that i want to show you this pretty much just so the the q a let's go with this one um i will start the poll the academy feedback poll while we're at it uh let's check for more questions and chat and then i'll follow any other questions but if you've got some and you're here with us go ahead and let them be shared with us yes and then uh also the information that we give every time this session is being recorded i'll edit it tomorrow or early next week it'll be posted on youtube i'll link it in the community post so subscribe to my community post to get notified when the recording is there if you want to re-watch any of those sections please leave us comments and questions over there i'll also add the slide deck to this post because there's a huge bunch of resources there's past academies there's stocks there's training and success center info videos that are very useful and blog posts so make sure to check those out in the resources on the community as i said the next sessions that we're going to do are early in the first week of july about process automation designer and then early in the first week of august about playbook experience and then very excitingly on i think on august 4th we'll also enter the early access phase of our new release which is tokyo so expect to see another what's new in the new release session uh academy session um in august so though that's about the timeline that uh is down the line all right well thank you so much for all of the the great uh aggregating of all the content in there together that looks so so handy like i'm i know i have most of those links but i certainly don't have them as nicely organized as you do so that makes it easy for folks to to find things so that's been really nice of you thank you all right thank you everybody for joining us today thank you andrew for being my co-pilot for the day it's always awesome to work with you um i will close out this poll and um that's about all i have for today thank you so much have a wonderful rest of the week and a wonderful weekend bye bye