Microsoft Flow – Avoiding failures or are you first do then think?

Do you like to avoid problems? Do you spend all day trying to avoid any possible problem making sure that nothing could possibly go wrong?

Or are you a person who first does something and then cleans things up when needed?

What is the better option?

Get everything right before you start

Imagine that you are making a cake. You look for a recipe, then you get some flour, you get some eggs, butter and all the other ingredients. You check for some more recipes in the internet, you adjust you ingredients. You put all of the stuff in the oven you wait 30 minutes and …

You’re cake didn’t cook. Ai, you forgot to turn the oven on!

The next time you cook a cake, you add some extra checks up front and this time you turn the oven on and with the previous experience you manage to build your cake.

This approach is probably ok when you make a cake. As you learn you will find that over time you get better at planning your work and the result will probably look better every time (unless you long lost sister rings and your cake burns!)

So how about creating flows in Microsoft Flow.

Imagine putting a lot of conditions in your flow. Just to check if you can copy a file from one library to another. Quite quickly your flow could look like this. Just so that you would avoid any problems.

This is what I call the Pre-Failure-If.

Now imagine that the Copy file action would fail just if any of the conditions is returning a false/No value. Therefore, you’re flow would only attempt to copy the file when all conditions are true/Yes.

You might even collect a reason for not calling the Copy file action. You could do this by adding a Set variable in every No branch and before you know it you need 7 steps just to handle one copy file.

No I’m going to take the idea from yesterday’s post. This now results in a flow like below. Just two parallel scope boxes (and if you don’t like the scope boxes you can also just skip the scope boxes and just add the actions in the parallel branches.

The above pattern if what I would call a Post-failure-if. It might not work in all situations but still it is a pattern that I have found made my flows a lot easier to read. By simply checking the success or failure of the flow actions we now have a similar construction built up with those many conditions. Where the conditions wee avoiding known issues, the parallel branches now also give us the option to correct the failure.