Power Automate flows have a maximum size of 500 actions. However, long before you get anywhere close to this limit, think about breaking a monolithic flow down into integrated smaller child flows
Child Flows
Child flows have a manual trigger
that is fired by a parent flow. Parents
can trigger many child flows. A child flow can be triggered by multiple parents.
Child flows can become a parent and trigger other child flows. There is no hard
limit on the number of flows that can be chained (or meshed) in this way
The parent flow can have any type of
trigger as long as it is not itself a child flow. For example, a parent instant flow can be
triggered from a Canvas App or a parent automated flow can be triggered from
Dataverse
Create Child Flows in a Solution
Both parent and child flows must
reside in the same solution. The child flow will not be visible when creating the
parent flow if this is not the case.
That said, it’s always a good idea to build flows, and all Power
Platform components, inside a solution anyway
Build Child Flows from the Botton Up
Because the intention is to build a
chain of flows, it’s best to start with the last child flow and build upwards
to the parent flow. This way each child
flow can be selected in the ‘Run a Child Flow’ action by the parent flow that
triggers it
Passing Variables or Arrays to a Child Flow
You can pass variables or arrays from a parent flow to a child flow. Here is a recent post explaining how to Pass an array from a parent to a child flow
‘Respond to a PowerApp or flow’ action
Child flows are required to have a ‘Respond
to a PowerApp or flow’ action
This action can be used to send a
simple success message to the parent to confirm the child flow has completed. It
can also be used to return one or more outputs back to the parent flow. Under these
circumstances, the ‘Respond to a PowerApp or Flow’ action would typically be placed
at the end of the child flow
However, even if it’s not required to
return a value to the parent flow, the ‘Respond to a PowerApp or Flow’ action
is still required in a child flow. If this is the case, because it’s required
but not adding any value, the action can be placed much earlier in the flow such
as in the 2nd example below
This leaves the child flow to
complete its run unmonitored by the parent
Putting the ‘Respond to a PowerApp or
Flow’ early in the flow might be useful if the child flow is updating a number
of Dataverse records or sending multiple emails and you don’t need the parent
flow to receive confirmation the child flow has completed
This also has the advantage that if
the parent flow is triggered from a Power App, the app won’t be ‘hanging’
waiting for a response
Who will run the flow?
Because child flows are initiated by a parent flow, by default they are run in the name of the person who created the flow
There are implications with this. If a child flow sends an email or creates a record in Dataverse, this will be done in the name of the person who created the child flow, not the person who initiated the parent flow. To avoid this issue, child flows that perform these kinds of actions should instead be run in the name of a service account. This can be configured in the ‘Run only users’ section on the flow details page
If a flow is triggered from a Canvas app, if you want to, you can identify the app user who triggered the flow using this technique: Identifying the Flow User
Yet More Tips!
Child flows can be triggered by more than one parent flow. This is a great way to avoid duplicating code. For the example where you have a child flow that sends an email, multiple parent flows can trigger the child flow and pass it the email’s recipient, title and content as parameters
Child flows are a great way to isolate errors when testing because each flow can be tested separately
Don’t be concerned about licensing implications of child flows. Calling a Child flow from a Parent flow counts as only 1 flow in the Per Flow Licensing Plan
I’ve already mentioned that child flows should always be created from within a solution. Instant flows created outside a solution cannot be added to it later. If you find you have mistakenly created a child flow outside a solution and need to add it, or want to duplicate a child flow from one solution to another, there is a workaround. You can temporarily change the trigger type of the child flow to a trigger type other than instant to add it, and then change the trigger back once it is in the solution
Microsoft: Create Child Flows