This blog is all about setting up an error management system so that you can be notified as soon as possible when an error occurs and better handle/organize these errors.
This includes being able to send an error including a general idea of what happened or where the error occurred.
We'll also talk about the "Configure Run After" settings.
Level: Beginner - Advanced
Hello!
If you're new to Power Automate (Flow) or are an experienced pro, I hope this post can be of use to you!
Introduction - Error Management by Default
Quality management is an important part in ensuring customer satisfaction, reducing costs, and making life easier for everyone - you of course probably already know this.
The best way to ensure good quality in a product or service (in this case perhaps a process), is to manage-in and design-in quality into the process - or in this case, a flow!
But of course, errors are still going to occur, especially in the beginning rollout stages of a new flow or process. So, if you've used Power Automate at all, you know that occasionally (hopefully not often) a flow run will fail.
Now, Power Automate will eventually notify you of a flow failing through an email and it is possible to see all your flow failures in the notification bell at the top of page (see below)
This can be helpful, especially when you want to see all the failures that have occurred, but most often it is very important or perhaps vital to know that a flow failed as soon as possible or at the very least the same day.
In order to accomplish this, we will first need to understand how flow actions work when a previous flow action succeeds, fails, times out, or is skipped.
Configure Run After Settings
Every action in flow has what is called "Configure Run After" settings, although sometimes they are not customizable and are grayed out. This is because the "Configure Run After" settings cannot be changed on the action right after the trigger. (See image below).
The "Configure run after" settings can be accessed by clicking on the ellipses (or the three dots) on the far right of a flow action (see image above).
Once you've selected "Configure run after", you will see a settings screen like the one shown below:
This showing the action directly above the selected action as well as a few options: is successful, has failed, is skipped, and has timed out.
Basically, what the settings in the image above are saying is that the "Initialize variable" action will only run when the "Approval Type" variable action (the one right above the selected "Initialize variable" action) has successfully ran.
But, of course, you can always change it to run if the above action (in this case the "Approval Type" action) has either failed, skipped, has timed out, or a combination of all four of the options.
For example, if you selected "has failed" AND "is skipped" the flow would evaluate that when it's running and if ANY of those scenarios occurred (if the "Approval Type" action failed OR was skipped) then the "Initialize variable" action would run.
So, it is important to understand that flow is going to look at EVERY ACTION even if a previous action failed and evaluate what the "configure run after" settings are to see if it should still run the action or not.
Note: If the settings you select don't include "is successful", you will then see a red dotted arrow instead of the usual black one. This shows that the action will not run if the above action succeeded.
You can probably get an idea of where I'm going with this right? If not, it will make much more sense in just a moment.
Really quick, though, before we get to the exciting part, let's go over what "has failed", "is skipped", and "has timed out" really means. If you already have an idea of what these mean, feel free to skip this next section.
Tip - Try renaming your actions as you build your flow. This makes it much easier for you or someone else upon opening the flow again.
Successful, Failed, Skipped, and Timed Out Definitions
Is Successful - Don't really need to explain this one but just to be certain, "Is Successful" means the action ran without any problems.
Has Failed - This one is also quite obvious. If the flow ran into a problem with the action and was not able to be completed it will fail.
Is Skipped - This one is very important to understand. An action will be "skipped" for two reasons:
1 - The action was on the side of a condition, switch, etc. that the flow didn't "go down". For example, if the action is in the "false" side of a condition and the flow run evaluated the condition as "true", all of the actions on the "false" side will be marked as "skipped". For those of you, like me, that would much rather see an image of this, here you go:
2 - The second reason is if a PREVIOUS action failed. (See image below)
Timed Out - It is more rare that this will happen, but an action will time out when, for example, an approval has been created and no one has responded in the time limit - which is currently 30 days. It might also time out because of perhaps a connection issue. Either way, it's probably a good idea to include this as a potential "failure" of an action since the flow didn't exactly "run through" all the way and the processes wasn't completed as it should've been.
Now that we understand how the "Configure Run After" settings work, let's get into how we're going to handle any errors!
TIP - You can use the 'Scope' action to group different actions together. This can make your complicated flows much more organized and copying large groups of actions easier as well!
Error Management - Send Email/Notification on Failure
There are a few different ways to do this, so of course, handle errors the way that you think is best for your situation. But, the idea behind the two methods is the same:
Whenever a flow run fails, we're going to send an email (or you could send a notification, create an error ticket item, Teams message, or whatever else you'd like).
As I mentioned before, there are two ways of going about doing this:
1 - Send an email/notification after a specific action in the flow (meaning not necessarily at the end of the flow)
2 - Send an email/notification after an error that occurred anywhere in the flow.
The second method is actually my preferred method, as the only real advantage of the first method is that you might have a good idea of what specific action failed.
But, there is a way using the second method to be able to get a general idea on what action failed or where the error occurred in the flow without opening it. Pretty cool!
Next, we'll talk about how to implement each method
Method 1 - After a Specific Action
This method involves using a parallel branch and will NOT send an error message when ANY failure/time-out has occurred. This method is designed around the idea of getting an error message when a specific action fails/times-out.
Here are the steps to implement this method:
1 - Identify the action that you'd like to be notified about if it fails.
Then, directly under this action, click on the plus and then instead of choosing "Add an action", select "Add a parallel branch". (See below)
Tip - You'll need to have another action below the selected action before you can add a parallel branch.
2 - Now you should see that a parallel branch has been added and you can now select the action that you would like to add. This action will be your email/notification action, so go ahead and choose the one that best fits your situation/needs.
Then, go to the ellipses (3 dots on the far right) of the newly added action and click on "Configure Run After". (See below)
Tip - If you're using an email, remember you can set the email importance to "High" or at least "Normal" so that it's more likely to be noticed.
3 - Once you've got the "Configure Run After" settings open, unselect "is successful" and select "has Failed" and "has timed out".
4 - This is very important! Be sure to add the "Terminate" action after the error email/notification action and set the status field to "Failed". I will explain why in the section "Remember this!" below.
Basically, configuring the settings as shown in step three above means that if the action above the email (or notification etc.) fails or times out, then the email will be sent out and the if-no branch on the other side will not run and all the actions will be skipped (assuming none of the configure run after settings were changed).
For example (see below), the "Send an email (V2) 2" action will only be sent if the "Get file metadata" action fails or times out. All the other actions on the other side of the "branch" will be skipped.
This method works great in general, but I believe it's best suited for scenarios when, at that specific action, it is more likely to fail and the effects of the flow failing would be the more impactful or negative as well.
Next - the method I prefer and personally use most often!
Tip - Use Microsoft Teams a lot? Try using a Teams action to notify a team or specific person about the error occurring.
Method 2 - After ANY Failure or Time Out
This method is my favorite because it allows our company to know of any failures/time-outs regardless of where the error/time-out occurred.
Here are the steps to implement this method:
1 - Place your error message/email/notification etc. at the very end of the flow. This will insure that you will be notified of any error that occurs. It's also important to make sure that it's outside of any conditions, switches, or apply to each actions as those can cause the error message not to be triggered (see the "is skipped" under the definitions section above if you want to know more).
2 - You guessed it. Go to the three dots on the top right, click on "Configure run after", and select "has failed", "is skipped", and "has timed out". Unselect "is successful". (See below). Basically, as we've learned already about the "is skipped" option, if there is a failure anywhere earlier on in the flow, all actions after the failed action will be marked as skipped. So, if the action above your error email/notification failed, is skipped, or timed out, that means something at some point in your flow went wrong.
3 - IMPORTANT - be sure to use the "Terminate" action after the error email/notification action and set the status field to "Failed". (See "Remember This!" section below for more info)
Getting an idea of what went wrong in your error message (Similar to Designer Workflows)
If you want to take the time and if you think you/your company would benefit from knowing in the error message/email an idea of what error occurred or where, you can set a string variable throughout the flow and then include that variable in the error message.
For example: at the beginning of a new step or section in your flow, you could set the variable to something like, "Beginning Copying Process".
Then, at the end of the process you could set it to something like, "Copying Process Complete" or whatever you'd like.
If the flow had an error occurred before the variable was to "Copying Process Complete", the variable would still say "Beginning Copying Process" and you would see this variable in your error message and know that the error occurred during the "Copying Process".
Getting the Link to your Failed Flow Run
First off, this is such a helpful thing to include!
I would definitely recommend implementing this especially because it is easy to do, makes life easier, and allows you to be more organized in fixing/seeing flow failures.
I won't go too much into how this formula works exactly, but here is the formula for an expression that you will need to use to include the link to the flow:
concat(
'https://emea.flow.microsoft.com/manage/environments/',
workflow()['tags']['environmentName'],
'/flows/',
workflow()['name'],
'/runs/',
workflow()['run']['name']
)The concat() function brings all of the text together into one string. The workflow() function can gather data from the workflow and the current flow run. If you want to take a look at everything it's grabbing, try putting the function: workflow() into a string variable to see what it returns.
Once you've created this variable, you can put it into an email as a link. Check out our blog HERE on how to do this.
Remember This!
An important note to remember when implementing either method is that Power Automate will set the status of the entire flow to "Succeeded" when an action is running after a previous actions has failed, is skipped, or timed out.
This means that you can't rely on view the flow run history and seeing that a flow run failed.
So, be sure to use the "Terminate" action after the error email/notification action and set the status field to "Failed". (See below)
Conclusion
And that is it, thanks so much for reading!
Feel free to like this post and subscribe to be notified about future posts!
Also, check out more of our blogs and know that we offer Power Apps, Power Automate, and SharePoint consulting services! We would love to help build your flow.
Check out our services:
P.S. Check out my Sci-Fi/Fantasy Novel! - benfetters.com
Power Platform Help: Power Apps, Power Automate, Power BI