Welcome again to another Logic Apps Best Practices, Tips, and Tricks. In my previous blog posts, I discussed some of the essential best practices to follow when working with Azure Logic Apps. Check out these Logic App tips and tricks!
Today, I will discuss another critical Best practice, Tip, and Trick that you need to consider when designing your business processes (Logic Apps): how to properly use and set up the Terminate action inside your workflow.
#47 Proper use of the Terminate action
When working with Azure Logic Apps, one of the nice actions at your disposal is the Terminate action. It allows you to halt workflow execution and explicitly set a status (Success, Failure, or Canceled) at any point in the process. However, using this action effectively requires careful attention to one particular setting: the Run After setting configurations.
In this post, we’ll look at a common pitfall when using the Terminate action and why the Run After settings are so important. Without proper configuration, the Terminate action may not execute as intended, resulting in unexpected behavior or end status in your workflows.
The Run After setting and its impact
Logic Apps has an important feature called Run After settings, which controls the execution flow between actions based on the outcome of the previous action(s). You can configure the Run After settings to define whether an action runs after a Success, Failure, Skipped, or Timed Out status. It is like a trt-catch capability per action level. By default, an action will be executed if the previous one is successfully executed.
The exercise
Let’s take the following simple exercise:
- We have a request-response scenario with a try-catch inside our workflow.
- If the business logic succeeded, we will return a 200
- If the business logic failed, we will return a 500
The workflow will look like this
One of the “problems” of this solution is that every single execution, whether it enters the catch scope or successfully executes everything inside the try scope, will present a successful run in the workflow run history:
To solve this, we will add a Terminate action inside the scope after the response to force termination with a failure status.
And if we test with our Postman tool, we will notice that now the workflow ends with a failure status as expected.
The issue with the default Run After settings.
At first glimpse, everything is ok and works as expected, but that will be an illusion, and you will find that unexpected behavior will appear. The issue is that if you do not set up the Run After settings for the Terminate action properly, it may not behave as expected. For example:
- Without explicitly configuring Run After settings, the Terminate action may be skipped, and this will, in many cases, such as the example above, force the workflow to finish as successful, even if that is not our intended outcome.
- The workflow might still complete as Success, even though the Terminate action was intended to set it to Failure or another status.
Here is an example of how you can emulate this behavior:
- If you now, without making any changes to the workflow, access to the run history from the Azure Portal, and resume a run, it can be a failed run if your desire:
- You will notice that the run terminates in success despite the Catch scope being executed.
The reason for this to happen is that we force a run from the Portal, and when it reaches the Response action, because no listeners are waiting for the response, this action is skipped. Because the Response action was skipped, and by default the Terminate action will be executed only if the Response is successfully executed – this is the default behavior. The Terninate was also skipped, which allowed the workflow to finish successfully!
How to properly set up the Terminate action inside your workflows
To properly set up the Terminate action to behave as expected in all our workflow scenarios, it is a fairly simple task. And I sincerely recommend you to implement this strategy in many scenarios – if not all – that we use the terminate action:
- Add the Terminate Action:
When you want to end the workflow execution at a certain point, drag the Terminate action to the desired location. It’s commonly used when you want to stop further actions from running, either when a condition fails or when an error occurs. - Configure the Run After:
- Click on the Terminate action and access to the Settings panel.
- In the Run After settings, make sure you select all the possible run after options:
- Is successful
- Has timed out
- Is skipped
- and Has failed.
This essentially means that regardless of the Response shape, if I enter the Catch, I will force the workflow to always end with a failed status. It’s crucial to set the right run after setting of the terminate action because, without that, the workflow might proceed as a success even if the Terminate action was meant to fail the flow.
Now, if we test our workflow again by resubmitting the run or by sending a new request from Postman, you will notice that the workflow will always terminate with a failed status, as expected.
So, why is this Important?
If you don’t configure the Run After setting properly, the Terminate action might get bypassed entirely, leading to the workflow finishing as a Success, or any other expected status, even if an error was encountered earlier in the process. This can lead to false positive results, where your workflow is marked as successful, but issues might have occurred that need attention.
Best Practices for Using Terminate Action
- Always Configure Run After: Before using the Terminate action, always review the previous action’s outcomes and configure Run After to match the expected flow. You can choose to run the Terminate action only if a failure or specific condition is met.
- In most cases, the best practice will be to set all the run after settings options to force the Terminate to run.
- Test for Edge Cases: Test your workflow with various conditions, including successful, failed, and skipped actions, to ensure the Terminate action behaves as expected. This ensures that no unexpected behavior occurs in your production workflows.
- Failing Gracefully: Always consider setting the Terminate action’s status to Failed if a critical action in your workflow fails. This provides a clear indication that the workflow encountered issues and should not be considered successful.
If you want to know more about Logic Apps Best practices, Tips and Tricks, you can download my handbook for free: The Ultimate Azure Logic Apps Handbook: 50 Expert Tips & Best Practices.
I hope you find this helpful! If you liked the content or found it useful and want to help me write more, you can consider buying (or helping to buy) my son a Star Wars Lego set.
