How reliable is Microsoft Flow? – Error handling

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

Avoidance

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";
  }
}
catch()
{
  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.