Recently I had a pleasure to show my presentation during Microsoft Flow Online Conference 2019 about building errorless workflows in Microsoft Flow. Actually, it was more about logging and debugging to receive errorless workflows in the end.

Watch the demo I presented during the conference below:

Errorless workflows

Anyone who has even a little experience with programming knows the “try – catch” pattern, usually substituted with “final” block. This construct is used to help handling errors in parts of the code, where programmers expect errors to occur. If error is caught, it wont’t trigger unhandled exception and push application into suspended mode, but can be caught and managed so that application operates without disturbance or at least user knows what to do.

The same approach can be used for Microsoft Flow. Even when we are authoring Flows trying to do our best, foreseen all possible exceptions in the ways Flow can run, still we can be surprised by situations totally independent from us, e.g. JSON body has changed and doesn’t match the schema, or secret key has expired and Flow gets access denied, or someone removed that item from database, that was used as a dictionary, or entity’s schema has changed and so on.

Try-Catch pattern in Microsoft Flow

When you are looking in the Internet how to implement such a pattern, you can fairly easy find already existing suggestions from:

• Rob Windsor: https://blogs.msmvps.com/windsor/2019/04/25/microsoft-flow-error-handling/
• Serge Luca: https://sergeluca.wordpress.com/2018/03/12/pattern-for-microsoft-flow-error-handling/
• Marcel Haas: https://www.thatmarcelhaas.com/post/advanced-error-handling-in-microsoft-flow
• Pieter Veenstra: https://veenstra.me.uk/2018/06/06/microsoft-flow-advanced-error-handling-throw-in-flow/

Oh, and there is already a template in Microsoft Flow templates gallery, you can simply use right away: https://flow.microsoft.com/en-us/galleries/public/templates/e8e028c6df7b4eb786abdf510e4f1da3/try-catch-and-finally-template/

The examples provided above are more or less complex, however they are all build around two functionalities of Microsoft Flow:

Run after

This feature is used to set up relationship and run sequence rules between actions. It lets you to set up that the next action should run if the previous: is completed successfully, has failed, is skipped or has timed out.

To access this setting simply click the epsilon icon (1) then from the menu click “Configure run after” (2), then define sequence relationship (3) and finally save your changes (4).

Scope

Scope is dedicated to group actions inside, so that later you can collapse it to make large workflow looking smaller and easier to “read”. It’s like a step in SharePoint Designer workflows. For the error handling scenario, they have also a second important role to play: if anything happens inside of them, they will reflect it like a mirror. If any error occurs inside a Scope, the whole Scope is errored. So they clearly show how the flow flows 😉

To add a scope simply click to add new action and then type “Scope”. Done.

Handling errors in Microsoft Flow

Run after and parallel block pattern

First approach bases only on “Run after” configuration and a parallel branch. To achieve it, simply add a parallel branch after the action you expect to fail, and then actions to both sides – e.g. correct flow on the left and send e-mail on the right:

Next, configure “Run after” of the action on the left side, so that it runs only, when previous completes successfully and then the one on right side, so that it runs only, when previous fails or is timed out, or skipped:

After all is configured fine, you’ll notice, that the right path is marked with red, dashed line, telling that its run after is set to run when previous action fails:

Run after and scopes pattern

This is the advanced configuration using three Scopes: “Try”, “Catch” and “Finally”. It follows the template existing here: https://flow.microsoft.com/en-us/galleries/public/templates/e8e028c6df7b4eb786abdf510e4f1da3/try-catch-and-finally-template/.

The “Try” scope should contain all the actions from the main flow of the process. “Catch” scope is configured to be run only if “Try” fails (for whichever reason). Then the “Finally” scope should run no matter what happens in previous actions:

Rob Windsor found, that there is a “result()” function that can be used in Logic Apps. However since Flow is built on top, it is also available there. What this function does is getting a JSON array with execution details of a scope passed as a parameter. I am using it in “Catch” scope.

Scope “Catch”

First I am filtering the array returned by the function “result('Try')“. As I wrote – it contains all details about execution of each action form the “Try” scope. Filter action here is used to leave only items from array, that contains status Failed’, or ‘TimedOut’.

Next, for each such item I am appending its details to a text variable, that then is sent to me via e-mail, so that I have full details about errors.

Scope “Finally”

In my case is used to always return response – because Flow is called via http request:

But depending on the scenario, response code is either 200 or set accordingly to the error that was caught by the “Catch” scope, e.g. 400 or 401.

Final note

Remember – you can use them as often inside a Flow as you need. You can as well implement multiple Try-Catch-Finally patterns inside a single Flow. It all depends on your specific requirements.

And that’s it! I hope you will find those patterns useful. If you need any support: leave me a comment or contact me!