I’ve been working on the development of what (for me at least) is a pretty complicated Microsoft Flow. This flow provides “intelligent” notification on whether to open or close the windows at my house. I’m doing this as a practical example to better learn Microsoft Flow, to increase energy efficiency, and to get some fresh air through the house. When developing this Flow one major challenge I ran into was effectively testing all the conditions that could apply which would factor into the decision whether to open or close the windows. These decisions were based on weather conditions which change on an hourly basis. This blog post will go through a couple of the approaches that I recommend when developing complicated Flow’s.

If you are interested in previous blog posts related to the technology I’m using to decide whether to open or close the windows check out these blog posts:

• How to re-write Log Analytics records in Flow
• QuickTricks: How to join unrelated data types in Log Analytics
• Tips when debugging sub-queries in the New Query Language For Log Analytics
• How to send any data you want to Log Analytics without code!
• Scheduling Log Analytics queries to run in Microsoft Flow
• Creating complex queries in the new query language for Log Analytics

The first step I took on debugging this Flow was to add an email notification at the end of every path which the Flow could go down. This included conditions where it made sense to open or close the windows or when it did not make sense to do these steps. This means that whatever path the Flow takes results in an email sent whenever the Flow is run. Below is a sample step taken which logs every variable I’m using in this Flow so that I can manually verify if the Flow performed as I expected it to.

This was an example for “Debug Email 4” which means it was the fourth path in the Flow which resulted in a decision to not open or close the windows. This same step was performed for each of the other paths with the same content (so it’s just a cut and paste with a slightly different name “Debug Email 1” vs. “Debug Email 4” as an example). This approach works really well when developing a Flow but it does generate a lot of email if you are running the Flow regularly.

As a result of the challenge above (lots of email), I added a debug flag to the Flow by initializing a Boolean value called “Debug” which could have a value of “true” or “false”.

Once this value has been initialized, we can use it to determine whether to send the debug emails.

When I need to make changes to the Flow, I change the initialization step to set the Debug to “true” and after saving that change debug emails flow again.

Summary: If you are developing complicated Flow’s, I highly recommend using a Boolean type Debug flag combined with debug emails on the various Flow paths like this blog post shows.