Asynchronous flows and Concurrency Control in Power Automate

In this post I will look at Asynchronous flows vs Synchronous flows, Concurrency controls and multiple response actions in Power Automate flows. Last week a few updates were added to the Respond to a Power App or flow action read this post for further details.

Remove the response action so the flow trigger completes instantaneously

When I first got this warning last week, it made me think that both the response and trigger steps in Power Automate I could really do with some additional investigations.

You might have noticed already this warning popping up in the Flow Checker. First of all we need to consider two situations here. Are you calling the flow from an app or are you calling it from another flow.

If your flow is a child flow, then removing this step is actually the wrong advice to give. Is your flow however called form an app then indeed you can remove the action that doesn’t return anything else than an acknowledgment of the request.

You could however move the respond action to the top of your flow if your flow is a child flow.

Asynchronous response

Asynchronous flows have been possible through the premium connectors, but within the standard connector this is also available.

If you use the classic UI then you will find the setting as below.

Or within the new UI

Within the Respond to a Power App or flow action you will also find the Asynchronous response setting that is switched off by default.

So what does this setting do? Image you have a flow that does whatever it needs to do, before a response is sent back to the user in an app or a flow. In the below example I used the delay action, but this could be anything that takes a while.

Now the respond to a Power App or flow action may just acknowledge that the request was received as now data generated by the flow is returned. This could be when the response action has now properties. But even a hardcoded status value would be treated as such.

Concurrency control in the When Power apps calls a flow trigger

When you investigate the twin-sister action of the Respond to Power Apps or flow action, the trigger that started our flow.

Then there is the concurrency control setting. This setting can be useful when you have multiple flows being trigger at the same time while you may update a single Excel file within your flow. This could lead to conflicting updates. Setting the concurrency to 1 will avoid many issues.

However if you have your response behaving in an asynchronous way, while your trigger allows only 1 flow to run at the same time, then you will bump into the following errror:

The concurrency configuration of workflow trigger ‘manual’ of type ‘Request’ at line ‘1’ and column ‘855’ is not valid. The concurrency control is not supported when the workflow contains actions of type ‘response’ without the operationOptions flag set to ‘asynchronous’.

Multiple Respond to a Power App or flow actions

It is possible to have multiple Response actions in your flow. It is important to make sure that all your responses return the same data structures (aka schema). It isn’t possible to have one response return just a number and another one just a text, unless you make both parameters optional. Which would then make the schema the same again.