[Music] hello and welcome to the workflow Academy in this comprehensive platform Academy video series we'll delve into the transformative world of workflow automation empowering you to build Monitor and optimize efficient workflows with ease join us as we explore the core tools of service now's workflow automation Suite to build flows and subflows playbooks and decision tables on the now platform hi my name is Lisa hollenstein and I work as an outbound product manager for the now platform my area of expertise is workflow Automation and I create enablement content videos articles and blogs on the now Community I have been with service now for 5 years and I've been part of the service now ecosystem since 2016 before joining service now I was a platform owner admin and developer at a customer in today's session I will teach you how to to build robust workflows with flow and action error handling and the tri flow logic as a quick reminder I may mention coming releases or product features that are still in development all timelines and features may be subject to change so please don't make any purchasing decisions based on anything I say today as we start into today's topic we'll first look at why we want to handle errors in the first place then we'll cover how we can best test for errors before looking at specific tools within the workflow products to handle errors some of you will likely think error handling is a given and why are we even talking about some reasons why we should build with error handling in mind but you'd be surprised how important it is to repeat this message most organizations struggle to quantify saved time down the road over invested time up front often times they just measure by how much time it takes to build something and don't factor in how much time is spent hunting bugs doing root cost analysis and generally trying to figure out what the developer had in mind while building something 3 years ago with that said when we develop with error handling and testing in mind we're able to minimize time spent on debugging and troubleshooting later and since we will see shorter downtimes this results in an improved operational efficiency second most likely we'll make our own future selves lives much easier by providing meaningful error messages with error handling flows can fail gracefully which speeds up service recovery and uces user frustration third using error handing allows us to proactively remediate issues with actions or subflows we can discover and identify new errors faster and since we already have some error handling in place it'll be much easier to implement preventative measures for those scenarios as well before we can test if something works we need to know how to test when something doesn't work how do we do that we test the unhappy path by breaking things on on purpose one way to test error handling and the try logic in flows is to use an action for which we can know it'll throw an error under predetermined conditions you can find the steps to create this example on docs but basically what it does is this there's an action input that's used in this little script snippet if the input is one the action will throw an error if it's any other value it'll complete without issues if you don't have a second service now instance or test remote system to test your integration against you can make use of services like Vetter and Postman these both have paid plans with more features and capabilities but for some occasional and limited scope testing you can generally get by with a free plans Vetter allows you to create a mock API endpoint that will return a predefined response you can even do waited responses to test random outcomes one of the examples later in this Academy has a 10% chance for success and 90% chance for failure full disclaimer this is not a paid sponsorship or official service now guideline but a personal recommendation while bter works for your outbound integration tests Postman provides you with a way to test inbound Integrations if you don't have test systems for those Integrations again this is a personal recommendation there's no sponsorship or paid ads going on the feature scope of postmen is so immense I can't even start to describe them all so I'll just recommend checking out their site and documentation with all the preliminary work and thoughts out of the way let's look at the first product feature for today evaluating errors in flow actions whenever we build flows subflows or flow actions we want to catch errors as soon as possible this prevents them from cascading up and we save ourselves from having to throw multitudes of actions and subflows for some of our more complex workflows one thing to mention before we dive in for my example today I am sending a rest message from a custom action but this is in no way limited to Integrations action error evaluation can be used in any action step like create or upgrade record wait for condition script step Jason or payload Builder etc for my example today I've created a bter endpoint with some reply rules that will return different response codes and messages based on the path I'm sending my rest call to the response code and message can then be processed by my custom action in case of success I'll return a code of 200 which in HTTP landan generally signifies success in case of error it'll return 401 signifying authorization issues to test the retry policies it Returns the 408 request timeout code a relatively recent but very useful addition is the test rest step button right within the rest step the rest step tester allows you to see the response for each possible input and helps you build out the rest of the action this is super useful to figure out if your credentials and handshake are correct and working it also helps understand what the response from the remote system might look like one common next step is to parse a retrieve Json payload into an object or array to map to action outputs and this is the best way to get a real example payload the first thing you can do to catch an error while calling a remote system is to simply try again this is most useful if you run into a connection timeout error or if there is a rate limit on the endpoint we provide a handful of retry policies out of the box that you can just use as they come but it's really easy to create your own as well either duplicate or adjust a default policy or create a net new one to Define how often and in which intervals your instance should try to execute that integration step again you can pick from three different retry strategies and submit an interval in seconds and account of how often this should be retried first exponential back off this option is there to exponentially increase the time interval for the subsequent retry attempts the multiplier is two the fixed interval just retries after a fixed time and then it'll retry again and then you can also honor the re try after header this is a header you can get from the request response after hand in connection or request timeouts with a retry option we now want to make sure we properly catch all non-successful step executions since we'll almost always get a response back from the remote system the integration step itself will be marked as completed and the action status will be zero and success because it was completely successful the issue is that not all of the responses are actually useful to us the error details will be hidden in the step details and not automatically surface in the action outputs often times these issues will only crop up later and later often times these issues will only crop up in later action steps or even subsequent actions in our flows for example when adjacent parcel step can't handle the response body because it doesn't contain the expected data this is where action error evaluation comes in for all kinds of steps we get to choose whether an error in this step stops the action and jumps into the error evaluation section or if we just want the action to continue with the next step we recommend only proceeding for errors in independent steps as soon as any subsequent action steps depends on this step success we should be using the error evaluation section the error evaluation allows you to build several conditions and condition sets and then then map values to the action status code and message you can drag and drop different conditions to order them for your use case some errors won't affect the outcome of Your Action in these cases you can check the box to don't treat this as an error to keep the error from surfacing in any flow or subflow you're using this action in if you do want the error to be visible in the flow but still want the flow to execute Beyond it we also have a solution for that the TR flow logic which we'll cover in the next section Additionally you can also handle and remediate errors on the flow level which we'll talk about right after the flow logic chapter before we move on we'll go through some recommendations for building out these conditions while there's no limit on the number of error conditions you can create each error condition requires evaluation the more error condition your action has to evaluate the potentially slower your action can run next we recommend to order conditions from specific to general error evaluation stops at the first matching error condition putting general error conditions first May prevent the action from ever matching specific error conditions 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 you may also want to identify a specific step so that a flow error Handler can take specific corrective actions for the failure another recommendation is to use descriptive error condition labels this helps you identify an error condition at a glance without having to open the details once we have everything set up for our custom action this is what it will look like now when when executed we get a nice Angry Red error status and the error message we chose is also displayed in a big right bar up next flow logic now that we've made sure to surface the action step arrows to the Action level if we so choose we'll learn some different design patterns that we can employ in our flows to make them as robust as possible the default behavior of flows when any action or logic has an error is that the subflow or flow execution will stop and result in an error State anyone familiar with JavaScript will know to use the tri cat pattern and it won't surprise you that there are some things very similar for flows as well the tri flow logic was first introduced in the S Diego release and is as of the Washington release now also supported in the flow diagram view when you wrap an action or sequence of flow steps within a TR Logic the flow will continue even if one of those steps runs into an error this error will be considered caught and you can define a couple of steps to execute when an error occurs for example we could create a task send a notification or log a message for further error investigation some important things of note when an error was caught with the TR logic it will not trigger the flow error Handler section try logic also only runs once there's no looping involved at this point either it runs successfully and the flow continues down the path or an arrrow is caught some steps in the then Branch are executed and the flow will continue down the path now that we have caught the error more often than not we do want to loop around a couple of steps until we are successful the default design pattern that we use for this is the do the following until flow logic this logic allows us to Define an exit condition with the desired outcome in this case for the custom action to return a success status the best way to think about this flow pattern is that it's very similar to the retry policies we looked at earlier just on the flow level and similar to the retry policies this is a good place to add in a little bit of wait time until we try again we can do that with a wait for duration of time flow logic and this is what these Loops will look like on the execution side the flow will repeat all steps within the do until logic until either the desired outcome or the maximum number of iterations is reached the default number of iteration ation is 1,000 and defined in a system property we currently don't recommend increasing that system property but this guidance may change once we've rolled out the flow engine V2 to all customers in the upcoming releases what is the flow engine V2 you ask in a multi-release effort our Engineers have done a complete rework of the flow engine to improve flow execution and Reporting this new flow engine will initially apply to any net new flow created after upgrading to the Washington release and then apply to all flow executions in a future update lastly through this effort we were able to increase the performance for Loops like the do the following until as well as enabling a new go back to flow logic go back to was one of the most uploaded feature enhancements on our idea portal this flow logic allows us to loop back to an earlier step in the flow and is often used after an if or elive condition while this is very similar to the do the following until logic functionally it is a more intuitive design pattern and it will enable some use cases that weren't possible before same as before for a robust flow we can also wrap any logic that might result in an error in a try logic to let the flow continue and then loop around until it's successful one of the benefits of using go back to instead of the do the following until logic is that we have more options on how and when and where to go back in our flows so let's look at these three design patterns in detail and learn when you would use each in this first example we're using the TR logic to catch possible errors and continue the flow regardless by placing the go back to in the error Branch we determine that we'll only retry if an error was caught this second example is very similar to the first however by placing the go back to after the try and an if condition we have more flexibility on when we want to retry the logic this time we're not restricted to only retrying in case of an error caught but if we have custom action outputs set in action error evaluations we can still retry for those cases this third example is another continuation and variation from the second this time we're not using the try logic because we have one of two scenarios either we already have all errors handled in the action and we have checked the don't treat as error checkbox in the error evaluation conditions or second we want this flow to stop if an error occurs and maybe we have configured the flow error Handler section accordingly we'll learn about that in the next part of this presentation this pattern will also allow us to retry for certain action status codes and other conditions based on action outputs I've mentioned this a couple of times already and now it's time to take a more detailed look at flow error handling the flow error Handler is a toggle at the bottom of your flow canvas when activated you can add a couple of steps and a limited selection of flow logic or subflows which will be executed when any step in your flow results in an error the this error Handler section is limited to 10 items common steps that are used in case of an error and are notifications logging or even a remediation subflow to set up the next execution for Success note that a flow with an error will not automatically restart a triggered flow would need to be retriggered a subflow can easily be called from within a do the following until or in a go back to Loop just as described earlier if you find that that similar remediation or notification steps are needed for multiple flows consider building a reusable subflow to handle this using a subflow will also get you around the 10 item limitation in the error Handler section subflows are even more powerful with a decision table as you can output a subflow as a decision result and then use the dynamic flow logic to run the subflow from the decision result you can learn more about this design pattern in my Coe article on the community now that we've got all the pieces and tools we need we're prepared to create robust flows subflows and flow actions but there's still more that you can do to make your own future developer life easier or to be nice to those who following your Footsteps in the future in this part of the presentation we'll look at some recommendations and guidance that you can Implement in your teams to make debugging and root cost analysis a breeze first up naming conventions when you build reusable actions and flows remember to give them human readable names so it's easier to find them when building flows and subflows be sure to also name inputs and outputs properly assign a default value for testing or just the most common value that will be picked to speed up usage later remember that actions and subflows can be categorized for better discoverability this is especially Al useful for application spokes that contain multiple different actions or subflows similarly a speaking description and annotation will help people choose the right action or subflow for their use case increased discoverability also helps you avoid duplicate efforts since you don't need to recreate existing logic and while on the topic of naming this is probably one of the most overlooked small but useful things you can rename actions steps which is especially useful if you're using multiple action steps of the same type this next tip is likely wellknown but it Bears repeating annotate your code this goes for flows just the same as for scripting however make sure your annotations are meaningful and don't just repeat the action or flow name annotations should always add value with a November Vancouver store update for flow diagramming annotations and step details are also available in diagram View this is in the 24.3 do2 version so be sure to check the application manager for available Store updates lastly some notes on the topic of scripting as a general rule we recommend using inline scripting as scarcely as possible as it's the least discoverable way to build flows and assign or transform values did you know you can even deactivate it completely with a system property you can get to it from the Overflow menu of any flow or subflow and then check out flow or subflow preferences to toggle it on or off if you need to transform a data pill when assigning a value use transform functions when possible these can even be stacked on top of each other these are best used to transform strings or daytime fields and the like one of my favorite snacks is to use a split on a comma or dot or colon and then under utilities you will find a transform function to get the first or last item in that resulting array this way you can extract a username from an email address the first item in in an array split at the at symbol or get the last part of an IP the options are endless there are even transform functions for basic math like getting an average or median for an array of numbers when you create custom actions the script step is very useful if the existing action steps are not enough to cover your use case we still recommend not letting IND individual scripts grow too large it is better to break them up into logical Parts you can also leverage existing script includes especially to service those useful Ule functions that every organization creates and make them discoverable and usable in flows and subflows and because no presentation is complete these days without mentioning gen code generation and code completion are available in script steps as well so let's wrap up the key points to remember about today's session first build your error handling bottom up and catch them as early as possible Second Use the triflow logic to catch errors and loop with do until or go back until you get a successful execution and third use flow error Handler to notify relevant stakeholders and run subflows to remediate before re-execution if you like this session please upload this video and whether you liked it or not this service is your chance to provide feedback or comments about this Academy I am looking forward to reading your feedback same goes here if you can find the link in the video description or use the QR code shown on the screen if you're interested in other topics Beyond workflows let me recommend my colleagues Academy series each of them covers a different part of the now platform we have content about conversational interfaces including virtual Agent mobile apps analytics next exper workflow core platform and of course artificial intelligence while on the topic of more content if you prefer to read up on topics at your own pace check out the workflow automation Center of Excellence on the community I have collected resources and links and I'm am regularly publishing new articles with best practices FAQ and guidance around flows playbooks and decision tables thank you so much for choosing to spend some time today to learn about workflow automation on the now platform and thank you for providing your feedback and questions to help us make these sessions better for you until next time bye