Troubleshooting Flows, Part 1: Failed Runs

The Need:
Identifying and fixing failed Microsoft Flow runs

Common Approach:
Plain old giving up, quitting Flow, and reverting to old processes

Better Method:
Tracking down errors from the 28-day run history page

A flow's run history is a goldmine of information about your flow's successes, failures, and frequency.
At the bottom of your flow's detail page is the "28-day run history" box. This box will show the ten most recent flow runs. Click "All runs" in the upper right to access the entire 28-day history.

There could be hundreds of triggered flows in the 28-day history. Luckily, you can filter the list to see only failed flows if you are trying to troubleshoot bad flow behaviors. "Failed" means that any one of its steps broke down. Your flow may have successfully downloaded an email attachment to a OneDrive folder and added metadata to the library, but failed to send an email to an approver because the approver left the company and no one updated the email address in the flow.

Below is a list of a flow history that was been filtered to show only failed runs. Click on any date/time to open the map of that particular failed run to see the outcome of each step in a flow, and to see the error message. I strongly recommend right clicking from this page to see the flow errors. If you click and then go back, you will lose the filter and you will lose your place.

The flow below acts when an item is created on one list (with people's names in text fields), waits for thirty seconds, and creates an item on a second list that uses Person fields instead of text fields. This flow has a Switch control with eleven cases in it (one case per stakeholder role). It parses information from the text field and adds it to the Person field. (Why we have to go through this parse step is a long story, but it ends in "because the way names appear on the first list don't reliably match the way the names appear in the Office 365 library. If it is not an exact match it won't work, so we have this crazy workaround. THE END.")

• Flow run failed: At least one step of this flow failed.
• Green check marks: A check mark on a flow step means that step successfully ran. The item was successfully created on the list. The variable was successfully initialized. The condition was met, et cetera.
• Error: Which step failed? The action, "Update_item_2" failed.
• Error Details: Why did "Update_item_2" fail? Because "the specified user could not be found" (in the Office 365 library of users).

There are eleven switch cases, so there is a lot of horizontal scrolling to find the error/failed step. We see a red exclamation point in the first condition control of switch case 1.

We have to click the condition box open to see if the condition step failed or if something else did. This condition box had a second condition box inside it. In the second condition we see a set variable step (successful), a delay (successful), and...
...
...Update item 2! (failed)

Once you have an error message and have confirmed where the failed action step is in your flow, you should:

1. Spot check a few other failed runs to see if they are failing in the same place or for the same reason
2. Click "Edit" to update or correct the flow
3. and then maybe return to the flow error page and resubmit it.

Pros and cons of resubmtting failed flows
There is a "resubmit" option on a failed flow detail page that will let you re-trigger the flow event from that page after you have fixed it. This could either spare you a lot of manual updating effort or it could trigger duplicates. If the flow failed early in its process you might want to resubmit it; if the flow failed at the very end, you might prefer to just manually complete the last few steps.

Good candidate for "Resubmit" flow:
Let's say you have a flow that adds an item to a list when an email arrives from a certain person containing attachments. An email arrives containing an attachment, but the item was not added to the list. Why? You did not have the correct "attachments" setting in the flow trigger, "When an email arrives." You find the failed flow in the run history, you edit the flow to the correct email attachment settings, you return to the flow history and click "Resubmit." You will watch on the screen as the flow goes through each step again--reassuring you with green check marks each time.

Poor candidate for "Resubmit" flow:
Let's say you have a flow that, when an item is created on a SharePoint list, sends an email to someone asking them to charge an expense against a budget, and then adds an equipment request to a second SharePoint list. It sends the budget email but fails to add the equipment to the list because of a typo in a switch case. You update the typo so future runs succeed but you do not resubmit the flow. If you resubmitted the flow, you would have a second email asking to deduct that expense from your budget, making your equipment request twice as expensive as it should be. In this case, it would be better to add the item to the equipment request SharePoint list by hand.

Before you lose your mind over some flow that claims it didn't fail but didn't do what you, The Human, wanted it to do, take a deep breath, count to ten, and click here for part 2 of the topic.

A note on a text:
The Martian by Andy Weir. If there is one thing we can learn from Space Pirate Mark Watney, it's that we can science the shit out Flow. Don't panic, check your records, fix your mistakes, move forward. If that line is from the movie and not the book, I don't care. I liked the movie better, even if some very entertaining B plots from the Hermes crew were left out of the script.