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

run a child flow

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

respond to a power app or flow

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

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top