Troubleshooting Flows, Part 2: Unexpected Outcomes

The Need:
Troubleshooting "successful" Microsoft flows that don't produce intended outcomes

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

Better Method:
Check your flow's status and its conditions

A Microsoft flow might fail to work the way you intended it to work, but that doesn't mean that it has "Failed." Part 1 of this post, Troubleshooting Flows: Failed Runs, walks you through how to identify errors in failed flows with "run history" information from the Flow details page. But even "Succeeded" flows might not do what you want. This post, Part 2, shows you how to troubleshoot flows that run successfully without performing the actions you planned.

Have you tried turning it off and on?
I am not being flip. Before you freak out about a flow not running the way you think it should run, go to the flow's details page and check the top menu. Is it even on?

There are two reasons why a flow might not be turned on when you expect it to be:

1. This flow got its start as a "Save As" copy of another flow. The default state of a Save As Copy is "off." Likely you copied a flow, started editing it immediately, and forgot it was off when you started to test it. Easy solution: Turn it on!
2. Microsoft helpfully turned off the flow for "your own good." This happens far more often than I think it should. Microsoft will disable a flow if it fails too often or if it isn't triggered often enough (and it will do this without asking). Hopefully you discover this before too many intended triggers have gone by. Ideally, you'll have someone on your team who will let you know right away if something seems broken.

Disabled flows are grayed out on the "My Flows" page.
You do not have to click all the way through to the Flow details page to see whether a flow is turned on or off, nor do you have to click all the way through to turn a flow on or off. You can select a flow from your "My Flows" page and right-click on the three vertical dots that appear to open an options menu. "Edit," "Save as," and "Turn on/off" and other actions are available on this menu.

Check your conditions!
A flow may run "successfully" and still not do what you want. I have found, in most cases, this is a problem with your condition steps. Check your conditions. Have you provided the right choices to the flow?

Did you pick the right type of comparison? Did you pick "is equal to" when you actually want "is not equal to"?

Is it possible to meet the condition you set? Are you comparing dates to an impossible degree of precision?(See the post, Using Dates in Microsoft Flow Conditions, for more information about this.)

Do you have a typo in your condition? Or on the SharePoint list/library/email rule the condition runs on?

Are you checking for a specific choice option on a Choice column in a SharePoint list? Did you select the right dynamic content? For Choice columns, there are dynamic content options for the column name and for the value of the column. If your condition is checking a SharePoint list for a specific value in that column, make sure you have the "value" dynamic content in the condition box.

Finally, are you comparing two things that CAN be compared? This comes up with Excel, where a number in Excel might be formatted as text. If you are trying to compare a number field from SharePoint to a text field in Excel (or vice versa), your condition won't come to the same conclusion that your eyes and brain do.

Emails from Microsoft
In an effort to be helpful, Microsoft will send flow owners emails when flows seem to be off track.

• Your flow has failed; we have disabled it: This once came eight full days after they turned it off. Rage, gratitude. At least they told me. I really might have missed it. But I still had eight days of backtracking to do.
• Your flow isn't running: Panic, then annoyance. It isn't running because no one is using it. If no one continues to use it, Microsoft will helpfully shut it off for you, even if you don't care that it is used rarely. So, you will have to go trigger the flow with a fake entry and alert everyone downstream that you are doing it. You do this because you set up a flow on purpose for these very rare events instead of trying to remember the weird steps required to do the task manually months apart. So again, rage, gratitude.
• A co-owner has made changes to your Flow: Is this an error? Do you need to check it out? Depends. Is your co-owner likely to break it? Depending on who the co-owners are and what they know about Flow and your processes, you may want to double check what their work. Gratitude. But also rage because Microsft doesn't actually tell you what changes they made and you have to go over every step anyway.

A note on a text:
Great Expectations by Charles Dickens. A classic tale of the importance of checking your assumptions and conditions when life doesn't turn out the way you'd hope.