Microsoft Flow – Advanced Error Handling – Recover from failure

In my series about error handling in Flow you will have seen the following articles:

• Try, catch and finally in a flow
• Throw in flow

So now that we have a way of handling flow, the next problem to address is recovery from failures. Up to now I sent an email to people looking after the Microsoft Flow system but some failures you might be able to recover from.

Before I’m looking at the how to handle the recovery, I would like to start by grouping flow failures into categories.

• Expected failures
• Known Failures
• Unexpected failures
• Handled failures

Expected failures

There are many possibilities for expected failures. I could imagines for example flow that copies a document but only does this when the document doesn’t yet exist. You could for example check if a file exists before copying a file using a Get File Content. If the file doesn’t yet exist we want to copy the file. In this case we wouldn’t want the flow to fail.

Known Failures

These are the error messages that we know about and they are handled like in mentioned in my previous posts and an email with the failure details is sent to Flow administrators. Administrators can now make a choice if something needs to be done or not.

This means that even though we maybe could recover automatically form these failures we choose not to and rely on manual checks and fixes.

Unexpected failures

The unexpected failures are failures that we don’t know anything about yet. The flow doesn’t handle these errors and when emails are sent to administrators using the try/catch pattern these issues need investigating. Most likely this could result in a change to the flow or change to the data that triggered the flow.

These are the kind of failures that shouldn’t happen but can’t be avoided.

Handled Failures

My last category is the category that this post is all about. Handled failures are a bit like known failures, however these are fully handled by the flow and the flow will restart itself. This could for example work when you get update conflicts. Although the solutions might of course not be easy to implement.

There are multiple ways of doing this.

1. Update the trigger so that a new instance of the flow starts
2. Add a loop around your flow

I don’t like the first option as:

• handling reruns of flow is complicated enough.
• It adds more runs to my flow (this might have licence implications)
• Flow is modifying data on the trigger making auditing more complicated.

To start I created a Restarts variable that will keep count of the number of restarts.

Then within the Catch scope I’ll increase the number of restarts and the flow will restart until the limit of restarts has been reached.

Time to look at a practical example. I have found that an Update file properties action has failed with a conflict.

Looking at the error details I’m seeing something like this:

  {
“message”: “The file DropOff/MyDocument.xlsx has been modified by i:0#.f|membership|john.johnson on 22 May 2018 04:02:44 -0700.\r\nclientRequestId: f7ed23e4-49e1-4d82-bd53-e86ced21f930\r\nserviceRequestId: 0e9b699e-8027-6000-b875-b173e6c592f3″,
“status”: 409,
“source”: “https:/ /mytenant.sharepoint.com/sites/mysite/_api/SP.APIHubConnector.UpdateListItem”,
“errors”: [
“-2130575305”,
“Microsoft.SharePoint.SPException”
]
}

I could now use a combination of the message, status, source and errors to handle the error. As a first step I could include in my Catch a Switch which responds in different ways depending on the status returned.

But what if … I have multiple actions responding with the same failures?

As with known failures, the handled failures will have to use the throw pattern. Just before throwing an exception another variable with a unique flow location could be set in such a way that your catch can identify where the failure occurred and within your catch you can then take the appropriate action.

For completeness, make sure that when the try-scope is successful you will need to set the restarts variable to the maximum number of restarts. This could result in your flow spinning around forever. Well at least until the flow timeouts are reached.