Office 365 – Microsoft Flow – How reliable is Microsoft Flow? – Part 4

In this post I’m going to look at error handling in Microsoft Flow.

During this series I have been going through developing reliable Flows by avoiding the error message.

Posts in this series so far:

Part 1 – Twitter feeds turned into emails with Flow failures

Part 2 – SharePoint lists alerts with Flow

Part 3 – Reliable Flows by avoiding errors


Before I continue I will first have a look at how error handling can work. In general I would implement one or both of the following:

  1. Error Avoidance
  2. Error Correction


Error avoidance is that we saw in part 3 of this series.

In traditional languages you would see something like this:

if ( x != null ) {
x.value = "test";

In the above example we first test that x exists before using x and properties of the object x.

Error Correction

Error correction is something that is however a commonly used approach in programming languages.

In traditional languages you would see something like this:

x = GetMeSomething();
try {
if ( x != null ) {
x.value = "test";
Write "Failed to get x";

In the above example we first test that x exists before using x and properties of the object x.

Now that we look a low coding solutions like Microsoft Flow is is possible to do error correction?

I’m going to start with my original Flow. Just a tweet trigger followed by a send email action.

Now I’m adding my apply to each again


When you look through the options in the ellipses menu you will notice that Configure run after is unavailable in the send email action:

The Configure run after is comparable to a catch in our code sample above.

In the configure run after you can now select when the action should be run:


Time to test this flow.

After the Flow runs I’m seeing the following where the For each action is failing and then my failure email is sent out and my flow is working without reporting failures in the history

Correction or avoidance?

It can be difficult to advise to choose between avoiding Flow errors or to correct the errors that have happened. In general I would probably suggest to do both. The main aim is to avoid any errors, however you might not have considered all possible options of failure and therefore placing some generic handlers of errors might be a good idea. However within Flow it is only possible to add a run after configuration to the previous action and you might end up making your flows too complex and difficult to manage when too many error handling steps are added to your Flow.





2 replies

  1. Avoidance is repeated as a heading above, i think that the second occurrence should have been Correction.


Leave a Reply to Pieter Veenstra Cancel reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: