Error Handling

As the final episode of the Function Library pattern in Flow I’m going to look at error handling. Before I go any further please do review the following posts:

Handling failing actions

During the development of a flow you will find many actions can fail for many different reasons. During the development you might not even have considered certain failures

In the app that I developed in the first 2 parts of this series I included a divide function branch. Of course I didn’t think that someone could try to divide numbers by 0 and my flow failed:

Error as a result from a compose action

Try Catch Pattern

I decided to add my try catch pattern to the function library pattern. I could now build the try catch around the whole flow however that means that I would only know that one of the functions called has failed but I wouldn’t know which one or in which manner.

With the following construction I added my error handling on the divide steps

Divide Catch

Wow, this is good, now I can collect the errors that happened in an Error variable. Ok, this pattern here is a bit simplified. I could do a lot more, but I don’t want to over complicate things at this stage. I could for example imagine that you want to handle some errors as critical (i.e. end the flow) and some other error message you might want to just ignore.

Also if you have for example REST API calls to SharePoint you might want to collect the error message returned by the output from these actions.

Reporting errors back to users

Now that I’ve got an error message to report there is just one step left to complete. Report it back to the user.

With a small change to my flow and I’m reporting the error back to the app.

Report Error to PowerApps


Now when the user tried to submit an invalid division, I can report the flow error back to the user

An app showing the error returned by Flow

Avatar for Pieter Veenstra

By Pieter Veenstra

Business Applications and Office Apps & Services Microsoft MVP working as a Microsoft Productivity Principal Consultant at HybrIT Services. You can contact me using

2 thoughts on “Error Handling with Function Libraries in Flow”
  1. it’s good. Rather than creating a generic message can we catch the original exception message?
    example: if my scope will fail because of multiple different errors (unauthorized or devidebyzero, the string is not in format), then it should send the final error list to user

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.