Logic Apps Best Practices, Tips and Tricks: #47 Proper use of the Terminate action

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, the Terminate action gives you precise control over workflow execution. It lets you stop the workflow at any point and explicitly set a final status: Success, Failure, or Canceled.

However, using this action correctly requires careful attention to one key detail: the Run After configuration. In this post, we explore a common pitfall when using the Terminate action and explain why Run After settings matter so much. Without the correct configuration, the Terminate action may not run as expected, which can lead to misleading workflow outcomes or unexpected run statuses.

The Run After setting and its impact

Logic Apps includes an important feature called Run After settings. This feature controls how actions execute based on the outcome of previous actions. You can configure an action to run after a Success, Failure, Skipped, or Timed Out result.

Each action behaves like a lightweight try‑catch mechanism at the individual step level. By default, Logic Apps runs an action only when the previous action succeeds.

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, cause the workflow to finish successfully, 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.

This happens because we manually trigger the run from the Azure Portal. When the workflow reaches the Response action, no listener waits for a response, so Logic Apps skips that action. Because the workflow skips the Response, the Run After conditions do not resolve as a success.

By default, Logic Apps runs the Terminate action only when the preceding action succeeds. Since the Response action did not succeed, Logic Apps also skips the Terminate action. As a result, the workflow completes normally and appears as successful, even though the logic intended to mark it as a failure.

How to properly set up the Terminate action inside your workflows

To make the Terminate action behave consistently across all workflow scenarios, the setup is actually quite simple. I strongly recommend applying this approach whenever you use the Terminate action—ideally in every scenario where you rely on it:

1. 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.
2. Configure the Run After:
   • Click the Terminate action to access 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 setup means that whenever the workflow enters the Catch scope, it always ends with a failed status, regardless of the Response action. Because of this, setting the correct Run After configuration on the Terminate action is critical. Without it, the workflow can still finish successfully, even when the logic intends to mark it as a failure.

If we now test the workflow again—either by resubmitting a previous run or by sending a new request from Postman—the result becomes clear. The workflow consistently terminates with a failed status, exactly as expected.

So, why is this Important?

If you don’t configure the Run After settings correctly, the Terminate action can be skipped entirely. In that case, the workflow may finish with a Success status—or another unexpected result—even when an error occurs earlier in the process.

This behavior can create false positives. The workflow appears successful, while underlying issues still require attention.

Best Practices for Using Terminate Action

1. 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.
2. 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.
3. 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.

Download Handbook

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.