Concurrency Limit

[srduval]

I have a flow that is running into the maximum waiting limit of 12. How/where do I change the trigger concurrency configuration.

The number of waiting workflow runs '12' has exceeded the maximum allowed limit of '12'. Try increasing the value of 'maximumWaitingRuns' in trigger concurrency configuration.

[Gopala_Krishna]

@srduval

[srduval]

@Gopala_Krishna  Thanks but, I know that setting, that's kinda what got me into this predicament. I have it set to 2 currently to reduce the number of simultaneous calls to the SQL Sever API. The parent flow loops through all the users in my organization and triggers this (the one with the concurrency control set) child flow. While waiting for the previous running flows to finish, the other flows go to a "Waiting" status. The number of flows in the waiting status is where I'm getting the current error, it's capped at 12 apparently and I can't see where to change it.

[FinderFees]

I'm not sure if you came up with a solution, but since Google seems pretty limited on the topic, I wanted to note what my colleagues and I found that appears to have worked.

If you manage your flows with solutions, export that solution. I think you can also export individual flows. Either way, what you are looking for is the flow's .json file. In the solution export you'll need to unzip the folder and go into Workflows > YourWorkflowName.json

Within the .json file, you'll want to find the property for "runtimeConfiguration" within the trigger. There should only be one property in your whole flow for this so just do a 'find' for that. By default there will likely only be one property within the concurrency object called "runs" and it will be set to whatever you have set the slider to via the UI.

Add a comma, and a new property for "maximumWaitingRuns" and the value you desire. In my case, I did 50. I don't know what a good number is but be advised some caution might be needed here on the number you choose.

Here is how it should look:

Save the file, and re-zip your solution back up. A note on this, you'll want to go inside your unzipped folder highlight all the objects in there and zip it with the same name as the one you originally exported. Don't just try to zip the folder or you're solution import will fail without having the .xml files in the zip ROOT.

Re-import your solution. Once that is completed, you can go to the trigger's "peak code" option and you should see your edit in there.

For testing, I used XrmToolBox's Bulk Data Updater to throw 50 records at a time to the parent flow. All succeeded, whereas before it was failing all flows after the child flow had queued up 11 'waiting' runs. Granted it did take awhile to crunch through everything (basically the reason it was hitting 11+ to begin with), so that is why I advise still being cautious about this as you may find yourself getting throttled by Microsoft for having flows running too slowly.

This documentation is what set me on the path to the solution. However just be aware this documentation is actually for Azure Logic Apps, it just happened to be that property we needed was the same.

https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-workflow-actions-triggers#change-waitin...

[sdikonda]

By any chance can we terminate the all the waiting flows and keep only the first one running.

[srduval]

@sdikonda I've used power automate desktop for this. I just did a quick and dirty flow to use the existing browser window (i think, maybe a new window with the URL for all runs) then had power automate loop through each flow and "click" the cancel for me, then refresh the browser and select the flow and click cancel again.