Handling Errors in flows with Microsoft Power Automate

Power Automate Errors Introduction

Digitising processes with Power Automate is excellent for reducing repetitive tasks or streamlining an existing process, but what happens when something in the automation chain fails? In this blog we will discuss various means of error handling in Power Automate and touch on ways to counter some of the more common problems which result in errors. If you are new to Power Automate read the Harnessing the Power of Automation here.

If the flow is built on your own Microsoft 365 account if any of the flows fail, then an email will automatically be triggered just to state that an error has occurred and give the flow name and link to it. (although we suggest not to run business wide flows on your own account to avoid licensing and connection based issue)

Handling Errors Power Automate

To get more detailed information in the email about the error the best method is to make your own emails
If within the flow you know that something has a potential for going wrong it is useful to pull that information and send it via email to avoid receiving the standard flow errored email.

A good example of this would be using the get manager action, if the manager does not exist the flow will fail, what you could do is add a branch action and set the action to only run if the above task fails to do this configure run after through the settings change the tick box from is Successful to Has Failed. On the branch add a send email action and include the email address from the get manager and detail within the message this user’s manager is not set within Active Directory, then you know to fix add the users manager within Active Directory.
The diagram below shows how to configure this action

Select the three dots to the top right of the new action to notify of an error this could be an email as demonstrated or any other form of notification such as a ticket within a compatible service desk tool or phone notification. 

Next unselect the is successful and select the has failed option, this way the email is only sent when the above action has failed,

NOTE: when setting the error actions directly beneath that for the subsequent action you will need to set the configure run after to is skipped (As shown below)

Parallel Branch for Errors

A better alternative to handle the errors generated for specific actions would be to add a parallel branch directly underneath the action as demonstrated below this looks cleaner and also avoids having to set the subsequent action to run if the above error action has skipped, it makes for a cleaner view as well as you can see from the second image that the branch to the left has the red dotted arrow indicating that this will only run when the above action has failed. 

Note: You cannot set run after options on the first action following the trigger, this is because the trigger has to be triggered in order to hit that action therefore it couldn’t have failed at the trigger level.

Solving problems before they become errors

The best way to handle errors is to avoid them altogether, now this may sound contradictory but by thoroughly testing your flow it should highlight any failings and give the opportunity to remedy them, read on below for some key tips on how to reduce errors within your flows:

• If the flow is triggered via a form ensure multiple users have submitted the form
• Again if its from a form trigger or data trigger and data is being moved from A to B then it is useful to test with different data types (numbers in text fields and text in number fields) also check if a long answer is given it doesn’t fail due to the field in the destination is capped at 255 character limit.
• Test test and then for safe measure test again
• If the flow is connecting to a API is the API online all the time what happens if it is offline, if possible consider testing the flow with the API offline
• When trying to figure out why a flow is failing it is useful to output all the variables or key pieces of information which is being fed through the pipeline into a text file or email so that you can analyse what is happening with the data on its journey through the flow.
• When processing data via Microsoft Forms or SharePoint Lists you can use the Submitted by or the Created by in SharePoint to get the person’s email who originally sent in the request, now if it fails you can alert them to the failing and pull in some key data to the email to inform them of why it might of failed and point the creator in the right direction ie re-submit the form or contact support or something.

Conclusion 

This is possibly the easiest way to build custom error reporting into your Power Automate flow, other options not discussed in this blog post include grouping actions into a scope then having an error action run after the scope, it is not recommended to build custom error handling after every action but if you are aware of potential issues with an action with no known way to remedy the core problem some basic error handling as demonstrated will certainly make troubleshooting a lot easier.

Learn more about error handling with flows with multiple actions in the Advanced Error Handling post.