Flow Designer with more than 50 sub flows executing parallelly

[Namita_Snow]

Hello community,

We have a requirement where users can select up to 50 multi-row values from a catalog form. For each multi-row value, we need to run sub-flows in parallel to trigger approvals and execute automation. Could anyone confirm whether it is considered a good practice to trigger multiple sub-flows from the main flow in parallel?

I would like to know, whether implementing this feature could cause any performance issues.

Thanks in Advance!

[OlaN]

Hi,

Is there any particular reason why you've chosen to run them in parallel ?

Based on the info given, I would probably have executed them one by one without the wait for the subflow to be completed. (Which is essentially the same as triggering them in parallel, without the need for extra configuration to set up the parallel execution).

[Namita_Snow]

Hi @OlaN ,
The requirement is to add users to an Azure group based on the domain selected in a multi-row variable set. For example, a user can request access for multiple domains, where each domain owner must approve the request. For each approved domain, the user will be added to the corresponding Azure group. Currently, we have set a limitation of five domains, so a user can select up to five different domains in the multi-row variable set. Approving the request and adding the user to the group are independent processes.

Currently, we have implemented this by calling subflows from the main flow without waiting. If we increase the multi-row variable set limit to 50, it could trigger 50 different subflow executions simultaneously. I would like to know whether implementing this feature could cause any performance issues, considering that the number of actions in subflow is nearly 60, including triggering notifications and calling workflow actions etc.

[OlaN]

I see. Well, it will have some impact on performance.
To what extent it will actually degrade the instance performance I cannot say.

There is a general rule of thumb that any Flow/Subflow should not consist of more than 50 actions.

The math does says that it can quickly grow, since 60 actions * 50 multirow variables = 3000 actions to store in memory, for just one maxed out execution of a Flow.

Given that this item can be requested many times the numbers can quickly grow even further.

To reduce the amount of stuff stored in memory, I would split out the (large) subflows, into at least two pieces. One containing the approval part, and one containing the automation after the approval is done.

That way the load is split up, because approvals will happen at different times, and will not force the instance to store all the actions for all the time while waiting for the approval.

Does this make sense to you?

[Ankur Bawiskar]

@Namita_Snow 

50 MRVS is very huge

Why not iterate each row and call subflow rather than running 50 subflows in parallel?

Let them run in synchronous and ensure even if subflow fails it still continues to next iteration

If my response helped please mark it correct and close the thread so that it benefits future readers.