Power Automate – Error handling

Hi folks,

Today we will check out some configuration you can do to handle your errors in Power Automate cloud flows. No system/flow is perfect, so always assume your flow can fail at any point, so let’s prepare for it.

Try-Catch-Finally

Usually, I start my flow with three “Scope” actions and renaming them to “Try”, “Catch”, “Finally” (sometimes Finally is more optional).

You might have heard about this from pro-code development. Scope acts like a container to put in other actions and the result outcome of one or more actions is also represented by the scope. So, if all actions in the scope are successful, the scope will also be successful. If only one action fails, the scope will also “fail” (have the status “failed”)

This technique will help us to define what will happen next, as even if a flow fails, it doesn’t need to end immediately. Using “Configure run after” within the settings of an action, we can define what will happen.

If you don’t know yet how to configure the run after, check out my blog post about it: Power Automate: Configure „run after“ – Cloudkumpel

First, if the “Try” scope fails (or is any other status than successful), we want some error handling. So, we configure the run after of the “Catch” scope to run only if the “Try” scope:

• has failed
• is skipped
• has timed out

Inside the “Catch” scope you can define your own error handling, like sending an email, writing to a database, Dataverse table or SharePoint list (e.g. logging the error in a seperate table/list or changing the status of an item) or other things you like to do.

As the “Catch” scope triggers, all actions will be executed. I also use the terminate action to set the status of the flow to “Failed” in the end to make it more visible in the flow run overview which run failed as otherwise the status of the run will be “successful” because all actions run successfully (even though one action failed, but it wasn’t the last action).

Afterwards you can also use a “Finally” scope, so if you have anything that needs to be done after the “Catch” block run or was skipped. Depending on your situation and the flow you are building, you can also not use the “Finally” scope. For example, if you are working with child flows and you want to provide a specific status to the parent flow by some text, you can use the finally if you change the variable in the “Catch” scope. I will also explain my way, how I handle errors in Child flows later.

Like the “Catch” scope, you can configure the run after, but you need to remember it’s running after the “Catch”, for example if you only want to run the “Finally” scope if the “Try” scope was successful, you need to configure the run after of the “Finally” scope as “Catch is skipped” as it will be skipped if the “Try” scope was successful.

Depending on your situation, you need to find the best configuration to trigger the right scope:

Child flow error handling

Using Solutions inside Power Platform is the greatest way to handle your development and provides a lot of features for your application lifecycle management (ALM). One extremely useful feature is the ability to use “Child flows” inside Power Automate cloud flows:

Just create a new flow inside your Solution (best create a new solution and not use one of the existing ones). To use a child flow, you need two actions:

• Trigger: “Manually trigger a flow”
• (Last) Action: “Respond to a PowerApp or flow”

The easiest to find the action is to search for “powerapps” as it is also used to respond to your Power Apps.

Instead of having one big flow or multiple flows doing the same stuff, you can build a more modular flow by using child flows.

Same as in my parent flow, I can use the “Try” – “Catch” scopes to build my child flow:

If there is an error inside my “Try” scope, the “Catch” scope will be triggered and terminate the current child flow run. If the “Catch” scope is skipped, it will respond to the flow. I often see people responding with a specific status (like 200 = “Successful” or Status = “Error”) whenever there is an error inside the child flow, so the parent flow will always receive an answer and then using a condition or switch to check the status.

Not only can it be difficult to check the correct responds (like will the child flow return “200” or “successful” or “created” on a successful run?) but also you are missing some Power Automate functionalities.

My child flow above is an easy one, from the parent flow I provide an item id, it will get the item, on error it will catch the error and if there is no error, my flow just gets a respond. Let’s see how this flow will do:

Within my parent flow (which triggers the child flow) I only need to provide some information:

As there is an item with the ID 1 in the list I selected within the child flow, my flow gets a successful responds:

Let’s now put in an ID which is not inside the list:

First, within the parent flow we see some yellow status on the action and a banner “X retries occurred”, within the child flow runs we can see the runs failed:

and checking one of the runs:

As we defined, the SharePoint action returned an error, so our “Catch” scope gets triggered and terminates the run instance and no responds is sent to the flow.

Retry Policy

The warning “X retries occurred” in the parent flow and the multiple failed child flow runs is coming from a feature “retry policy”. You can use this feature in nearly every action to define how often an action is executed in case of an error.

A retry policy applies to intermittent failures, characterized as HTTP status codes 408, 429, and 5xx, in addition to any connectivity exceptions. The default is an exponential interval policy set to retry 4 times.

Power Automate Retry Policy Description

You can find the retry policy within the settings of an action:

Of course, as default, the retry policy “Default” is selected. You have four types of retry policies you can use:

• Default: exponential interval policy set to retry 4 times
• None: Only try it once
• Exponential Interval: Retry within a range of time (like increasing from a few seconds to a couple of hours) and retries (like up to ninety retries)
  • Count*: retry count 1-90
  • Interval*: The interval in ISO 8601 format
  • Minimum Interval: The minimum interval in ISO 8601 format
  • Maximum Interval: The maximum interval in ISO 8601 format
• Fixed Interval: Retry within every specific time (like every 20 seconds) and retries (up to ninety retries)
  • Count*: retry count 1-90
  • Interval*: The interval in ISO 8601 format

Instead of always returning a value to the parent flow and trying to handle it by yourself, you should consider using the retry policies within Power Automate in combination with the run after configuration (and scopes).

Use child flow to log errors

Child flows can also be used to log errors. If you have multiple flows, you don’t want to handle error logs differently for the whole solution within your “Catch” scopes. You can create a child flow which all other flows reference to. Here is an example by just sending an email:

<p>Error in flow "@{triggerBody()['text']}"<br>
Environment: @{triggerBody()['text_1']}<br>
Flow ID: @{triggerBody()['text_2']}<br>
Run ID: @{triggerBody()['text_3']}<br>
<br>
<a href="https://make.powerautomate.com/environments/@{triggerBody()['text_1']}/flows/@{triggerBody()['text_2']}/runs/@{triggerBody()['text_3']}">Click here to open flow run</a></p>

As every flow and run id is different, you can provide this information to the child flow. Using a single place for your error logging makes your maintenance and administration easier. To easier access to flow run from the logging or email, you can provide a link:

https://make.powerautomate.com/environments/{Environment ID}/flows/{Flow ID}/runs/{Run ID}

Within the “Catch” scope you can trigger the child flow:

Flow Name: @{workflow().tags.flowDisplayName}
Env ID: @{workflow().tags.environmentName}
Flow ID: @{workflow().name}
Run ID: @{workflow().run.name}

Within Power Automate, you can use the expression “workflow()” to access the information of the current running flow run. No matter which flow inside your environment triggers the child flow “Log error”, the content within the table/list/database, email etc. will always be redirect to the flow run error, if the retry policy didn’t made it in your defined time.

Thanks for reading, I hope you liked it and it will help you!

Glück auf

Marvin