Concurrency in the Power Platform
Table of Contents
The Power Platform has a number of places where you can set or control concurrency. In this post I will have a look at the concurrency options available in the Power Platform and compare the different options in Power Apps and Power Automate. A while back I already wrote about the sense and nonsense of the concurrent function in Power Apps, in this post I will have a look at running multiple flows in a concurrent way or in a sequential order.
My Flow in Power Automate
I’ve create a simple flow that will be called from my Power App. The flow will generate the current time and then return this time.
You might find that most of your flows called from Power Apps will do more complicated jobs, however I this post I want to focus on the calling of the flows rather than the running of the flows.
I’ve called my flow Concurrent Flow. This name will be used within the Power App described below.
My Power App
My app has two buttons. The first button (Run All) will call my flow 13 times. For each run a variable will be set to the result of my flow. These result variables will be displayed in labels in my app.
Concurrent function
My second button does exactly the same, however the Run All Concurrent button will use the concurrent function in Power Apps to call my flows. Once again the same Result 1 up to Result 13 variables are set to the result of the flows.
Run results
When I click on my first Power App button I will find the following results in my app.
The 13 flows all take about 10 seconds in total to run.
Then when I click on my second button and the flows run in concurrency mode all my results are returned within 2 seconds.
Ok, that is a lot faster! Note that the results however aren’t coming through in the same order as the flows were started. Or at least we have lost control over the order that the flows are run. This of course is what you would expect when you use the concurrent function. This does mean however that if your flows do any updates for which you do care about the order of things happening that you might not want to use the concurrent function.
Concurrency in Power Automate
But that is not all yet!
In flow you can also control concurrency, but before I go into that I want to have a look at one of my older posts. In my Trigger limits in Power Automate post I’ve looked at the limits that you may hit. When you hit these limits you might even run into the Error 429 error and your flows may start to fail.
For the Power Apps connector in your flows there isn’t a published limitation, however for most other connectors you will find the limits in each of the connector documentation pages.
As we now might run multiple flows and imagine if we ran multiple instances of the app at the same time. The problems of a connector overload could become more likely. We can of course look at setting the retries of the flows however it might be easier if we could control the number of flows run at the same time.
The above Concurrency Control option is available on a lot of the triggers in Power Automate. Be careful however, the warning is very clear!
Concurrency control changes the way new runs are queued. It cannot be undone once enabled.
I’m going to set my concurrency to 3 hit save and then …
The concurrency configuration of workflow trigger ‘manual’ of type ‘Request’ at line ‘1’ and column ‘526’ is not valid. The concurrency control is not supported when the workflow contains actions of type ‘response’ without the operationOptions flag set to ‘asynchronous’.
Ok, that was unexpected!
Asynchronous Response
Time to find that Asynchronous Response option in my Respond to a Power App or Flow
Once I switched the Asynchronous Response option on the problem goes away.
This all looks exciting.
When I look at my flow runs I’ve got 13 flows running successfully in 4 seconds.
That looks promising however when I look at my app. My result variables don’t seem to get set any more.
Set( Result1, ConcurrentFlow.Run().information );
For the coders, it looks like the await code doesn’t exist in flow. For the Low-Code people, the Await will wait for a result form an async call made.
Ok, I’ve made a fundamental change in my flow, therefore it might be worth it if I reconnect my flow to my Power App.
After I reconnected my flow however still now positive result.
I created a new button and make this button set a variable myVar.
Set(myVar, ConcurrentFlow.Run())
the structure of the data is recognised
However the no information is returned even though when I check my flow run the information is returned.
For now I would be very careful using the Concurrency Control setting. If your flows need to return any data back to Power Apps then you might not want to use this setting. For flows that don’t use Power Apps or flows that don’t respond to Power Apps this could quite well be a life saving setting.
Interesting research. Thanks for posting. I actually had no idea PowerApps had a concurrency feature. I recently wrote some Power Automate flows where I make use of concurrency and indeed had to spend time “fine tuning” the right number for concurrency to avoid getting over the limit of number of connections in 5 minutes. This in combination of the dreaded 5000 limit in sharepoint list views I’ve been having hell of a time learning Power Automate recently.