Exception handling

Completed

Exceptions can occur from virtually any action. For this reason, most actions’ properties include an On error button. This button provides access to the action's exception handling settings.

Action-level exception handling

In the initial example, you learned that the client's database might be inaccessible. This condition causes the action that communicates with the database to produce an exception.

To prevent this condition, open the action’s properties, and select the On error button.

Exception Handling in the Open SQL Connection action's properties.

In this view, you can configure the action’s exception handling behavior by either activating preset rules or adding new ones. These rules take effect if this specific action fails, and they run in the order in which they're arranged:

The populated Exception Handling tab in the Open SQL Connection action's properties.

Note

You can drag and drop any user-created rules to rearrange them.

In the preceding case, when this action fails, it retries one more time after 2 seconds. Then, it runs a subflow that sends an email to notify the administrator about the database status. Additionally, the action changes the value of a variable that indicates that the database is down.

By default, exception handling takes effect when any exception occurs while this action is running. However, you can configure it so that exception handling occurs only on a specific type of exception. Each action has specific exception types that it might produce:

The populated Exception Handling tab in the Open SQL Connection action's properties with selected exceptions.

In this example, the exception handling rules apply only when the Can't connect to Data Source exception occurs.

Block-level exception handling

There are cases where one can't be certain which action is at risk of failing, and it isn't practical to apply the same exception handling rules to every single action.

For example, consider a flow in which Power Automate desktop app interacts with the web portal. If at any point during this task the portal or browser becomes unresponsive, the preferred action is to close the browser, launch it again, and restart the entire web portal interaction from the beginning. However, a web portal interaction can span tens, or even hundreds of actions; so assigning the same exception handling rules to each action individually is impractical.

The On block error action allows you to apply one set of exception handling rules to an entire block of actions:

The On block error action's properties dialog.

Actions in between the On block error and End actions are affected by the block’s exception handling rules:

The Workspace with an example using the On block error action.

In this example, if any of the actions within the block fails, the block’s rules take effect; a subflow that closes the web browser runs, and the entire block will be repeated, thus preventing the flow from crashing due to a nonresponsive web page or browser.

Exception handling priorities

The order in which exception handling is applied is from the bottom up; this means that, in case an action fails, its individual exception handling rules take effect immediately. If that isn't enough to resume the flow, any block-level exception handling takes effect.

Therefore, any action-level exception handling rules run before the respective block-level rules.