Handling errors when Power Apps triggered flow occasionally runs too long

When Power Apps Canvas Application triggers a flow, the app will be waiting the flow to finish for some time. Depending on the source of documentation (mainly System requirements, limits, and configuration values for canvas apps – Power Apps | Microsoft Docs or Limits and configuration – Power Automate | Microsoft Docs) and the device used the maximum time waited for the results is something between 60 to 180 seconds. In my tests browser on the laptop tolerated longer runs when in comparison iPad (iOS 14) didn’t survive for more than a minute. Failing instance of a flow will show you following error:

The execution of template action ‘Respond_to_PowerApps’ is failed: the client application timed out waiting for a response from service. This means that workflow took longer to respond than the alloted timeout value. The connection maintained between the client application and service will be closed and client application will get an HTTP status code 504 Gateway Timeout.

When flow runs longer than expected by the application, things easily start going to unwanted direction. The instance of a flow keeps running no matter if the app is still waiting or not. On the other hand the application gives up at some point and if your monitoring the app, you will likely see something like network error on the log. When this happens, the applications might automatically try again up to 4 times to run the flow – or then not. If there is already performance or throttling issues with data source connected to the flow, this might make things even worse.

You can respond back to the application from the flow. This response can then be used in the application to for example handle results (and errors if reported) happened with the flow. Unfortunately I don’t know a way to catch that “network error” on the application side. That means you want to avoid this happening to keep control of things.

I encountered a flow that most of the runs finished within reasonable time (~10 seconds) but once in while took minutes to finish. That application expected to receive a response from the flow confirming a successful run before going forward. I tested the following solution for keeping control of the process.

In the flow you want to use all possible means for making sure that you send a response from every triggered instance of the flow. So I decided to make parallel branches after the trigger. First one would act as timeout for possible issues. First we need a delay according to the max allowed run time. Since I’m running this flow with iPad, I ended up using 40 seconds. Then we send a response and as last step terminate the flow. The another branch will contain the actual tasks of the flow. And if tasks are successfully completed before timeout, we need to respond to the application and terminate the flow (before “timeout branch” kicks in).

This setup makes better chances to receive some response from the flow even when things take too long. I’m using this control to inform user about failed operation and instruct him to try again in a while.

This solution is good enough as a work around for me for now. It is not perfect by any means. By side effect the flow instance is always running at least 40 seconds (or equal to your timeout setup) and this in turn makes inspecting run durations harder.