Ingenious way to take your Power Automate error handling to the next level


Power Automate have built in features to handle errors and exceptions. So every flow you create, should be setup in a way where you place all your flow actions in a scope. By configuring your flow this way you can setup another action after the scope which will only run when any action in the scope fails, and thus send out a notification to the appropriate person. This use of Try-Catch blocks for error handling is the standard method in numerous programming languages, and for a detailed walk-through on this specific subject in Power Automate you can check out this guide.

This setup is good for quickly letting the right people know when something goes wrong, but if you’re dealing with lots of flows or logic apps, you might need better control over your error handling. So in order to achieve that, I will take this practice a couple of steps further. This is achieved through creating a couple of simple tables in Dataverse or SharePoint and integrating those with the PowerApps- and Automate. So, let’s take a more detailed look at a solution that makes this possible.

The initial table acts as a flow monitoring log and includes the following columns:

When a flow runs fails, the following action will be the first action in our Catch/Error handling scope, which adds a new row to the above table:

In the first column we set the flow name with the following expression:
workflow()?[‘Tags’]?[‘flowdisplayname’]

Thereafter we set an Error category, I will come back to this later but it’s essentially to be able to configure who’s getting the notification from another source than what’s configured in each flow. Also, it let’s you more easily send the notification out to a group of people.

In the next column we set a value for the error message, here you can use this expression: actions(‘XMLconvert’).error.message to add the error message to the table. Note, you can only reference one action at the time, so this is only usable if one specific action is prone to failing.

Next, we add the link to the specific flow run which have failed. Power Automate have a straight forward way of building the links for each flow run. It’s https://make.powerautomate.com/environments/”environementId”/flows/”flowId”/runs/”runId”.
Then the code for this will be as follows (which can be pasted directly into an action):

https://make.powerautomate.com/environments/@{workflow()[‘tags’]?[‘environmentName’]}/flows/@{workflow()[‘tags’]?[‘logicAppName’]}/runs/@{workflow()?[‘run’]?[‘Name’]}

The last value in this table will be the runtime of the flow.

The second table looks like this and is quite straight forward. It has the all the users who will receive an email when a flow in a specific (or all) category fails.


So, the 2nd and last action in the error handling scope is then to send out an email to every person within the category of the specific flow run, like this:


Once we’ve configured our flows like this, we can add an application to manage both of these tables. To achieve this I’m using Powerapps.

I’ve put together a simple app that shows errors for certain time periods. Additionally, I’m highlighting which categories of flow runs have seen the highest number of failures lately.

Once I click on one of these sections an overview will popup, which shows the failed flow runs displayed in a gallery, filtered on the specific time period I selected.

You can configure the gallery the way you like, but in my case I’ve added the possibility to sort the flow runs by category. I’ve also implemented the possibility to open a new tab with the specific failed flow run. Here I use the launch function in PowerApps in the OnSelect property of an Icon:

Finally, by selecting ‘configure’ on the home screen of my app, I can set up the email alert configuration. Here I use the Office365Users standard connector, to search through users in my organization, mark them with the category of flows they should recieve a notification from, and add them to the email error table mentioned above.



In conclusion, the configuration we’ve discussed is straightforward yet significantly enhances your overview of failed flow runs within your organization. This approach is ideally suited for those with numerous flows in operation, yet its simplicity allows for easy implementation in any context. While the Power Platform Admin Center environment overview offers some analytics, it lacks the centralized capabilities for managing email alerts. With the method outlined here, you also gain direct links to failed flow runs, the ability to categorize these runs for group email notifications, and the option to log error messages. It also let you view historical data beyond the typical 30-day limit and is not locked behind admin privileges.