Workflow Automation CoE > Flows > Flow and Action Error Handling > Level 2: Flow Logic - Try, Do the following until, Go back to
Overview
Now that we’ve made sure to surface the action step errors 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.
Try Flow Logic
When any action (or logic) has an error, the default behavior of flows is that the subflow or flow execution will stop and result in an error state. Anyone familiar with JavaScript will know to use the try … catch pattern, and it won’t surprise you that there is something similar for flows. The Try flow logic was introduced in the San Diego release and is now supported in the Flow Diagramming view, as of the Washington release.
When you wrap an action or sequence of flow steps within a try 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.
Note
When an error is caught with the Try 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 error is caught; some steps in the Then branch are executed, and the flow will continue.
Do the following until Flow Logic
Now that we’ve caught the error, more often than not, we want to loop around a couple of steps until we are successful.
The default design pattern 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 similar to the retry policies we looked at earlier, just on the flow level. Like the retry policies, this is an excellent place to add a little wait time until we try again 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 iterations is 1000 and is defined in a system property. We don’t recommend increasing that system property, but this guidance may change in future releases.
Go back to Flow Logic
Go back to was one of the most upvoted ideas for Flows on the Idea Portal. It is available for new flows with the Washington release and all flows in an upcoming release. This flow logic allows us to loop back to an earlier step in a flow and is often used after an if or else if condition. While this is very similar to the Do the following until logic functionally, it’s a more intuitive design pattern and will enable some use cases that weren’t possible before. As before, for a robust flow, we can wrap any logic that might result in an error in a Try logic to let the flow continue and then loop around that until it’s successful.
Go back to – alternate design patterns
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, when, and where to go back to in our flows. Let’s look at these three design patterns in detail and learn when you would use each.
Example 1: Go back to from Try error branch
In this first example, we use the Try logic to catch possible errors and continue the flow. By placing the go back to in the error branch, we determine that we’ll only retry if an error is caught.
Example 2: Go back to from after Try logic
The second example is 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 being caught, but if we have custom action outputs set in action error evaluation, we can still retry for those cases.
Example 3: Go back to with custom action status
The 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 condition OR we WANT this flow to stop if an error occurs, and we have configured the flow error handler section accordingly. We’ll learn about that in the next chapter of this article series. This pattern will also allow us to retry for specific action status codes or other conditions based on action outputs.
Continue Reading
