It was only recently that I noticed a really simple trick in Power Automate which has led me to improve my error handling in my flows. These tricks will allow you to implement error handling into your Power Automate flows to allow you to easier identify issues as soon as they happen and reduce down time for solutions.
Step 1 in Error Handling – Configure Run After
When developing an automation solution using Power Automate, you will notice that when you click the …, one of the options that appears is ‘configure run after’. Keep in mind this option will only be available on your second action and actions that follow it. You cannot specify the run action to take place on the trigger, or on the first action, which will look at the previous step (the trigger).
When you select ‘configure run after’, Power Automate allows you to set the run configuration for the current action depending on the outcome of the previous action.
If the flow step / action that you have selected to configure run after for is the next step in the process you want to automate, the option to check would be ‘is successful’. This is because if the steps in your workflow are successfully being run, Power Automate should move to the next step you are trying to automate.
However, if the flow step / action you have selected to configure run after for is an error handling step, you should select the appropriate options to error handle the step.
Keep in mind that you shouldn’t check these options if the flow step you are configuring run after for is a step in your workflow as opposed to an error handling step. Examples of error handling steps might include, sending an email to a solutions developer or the team that manage the solution so they are able to fix it. Or, you could follow multiple steps such as creating a log of an error in a SharePoint list, prior to notifying a team via email of the issue, but with a link to the error log.
Implementing a best practice – Email Notification
When using an email notification as an error handling step, you should keep in mind who the email is being sent to, and whether it should actually be an individual. With regards to solution sustainability, you might decide not to have the email be set up to go to an individual who at some point will leave the organisation and no longer receive the emails.
The alternative to sending an email to an individual as an error handling step could be to either send an email to a shared mailbox, for the team that manage the solution being worked on, or to a group mailbox.
A step further – Scope
The scope action effectively allows you to group flow steps together and organise your flow in a way that will allow you to error handle in bulk. Should you wish to only receive notification of an error after one of 3 grouped steps fail, you can use scope to group 3 actions together and configure them as one. An example of this is if you wanted to notify someone of a flow failing, regardless of which step failed. You could put each action within a scope action and put the notification after the scope action then configure run after on the final step of the flow.
In this example, the action labelled ‘Error Handling – Notification to IT’ will only run one of the flow steps within the scope action have failed causing the entire scope action to fail.
You can also use the ‘terminate’ step to stop a flow after an error handling step has succeeded, preventing the rest of the flow from running.