Child Flows in Power Automate: Building Processes Modularly

Anyone who packs a process with dozens or hundreds of actions into a single flow in Power Automate eventually notices how confusing it becomes: every change means long scrolling, errors are hard to pinpoint, and a sub-step you actually need in several places suddenly exists three times in slightly different variants. Child Flows solve exactly this problem. A parent flow calls one or more child flows, passes them inputs, and then processes their return values further, much like a function in classic code being called from within a larger program.

For companies that use Power Automate in production, this pattern is especially relevant when the same logic appears in several processes, for example determining approvers, formatting amounts, or error logging. Instead of rebuilding this logic in every flow, it is built once as a child flow and called by all matching parent flows. If the logic changes, a single adjustment in one place is enough.

What is a Child Flow?

A child flow is a completely normal cloud flow with one special feature: it does not start via a classic trigger such as a schedule or a new item in a list, but is started directly by another flow. Microsoft describes in the official documentation Create child flows, that this requires a solution with at least two flows:

• the Child Flow, nested inside the parent flow, with the smaller tasks that are actually executed
• the Parent Flow, which can have any trigger and calls the child flow at the appropriate point

A parent flow can contain several different child flows, depending on which sub-task is currently needed. It is important that the parent and child flow are created directly in the same solution, because only then does Power Automate automatically link the two during later export and import, without URLs having to be maintained manually.

Why modularization pays off

Microsoft summarizes the benefits in the Guidelines for reusable code with child flows, and in practice these benefits show up quickly:

• Modularity: Reusable building blocks can be built into different processes without you copying logic.
• Maintainability: Small, focused flows are easier to read, and an error can be tracked down specifically to the exact building block that caused it.
• Scalability: New requirements are handled as an adjustment to a single child flow, instead of rebuilding the entire process.
• Precise control: Through clearly defined inputs and outputs, you control exactly which data flows between parent and child flow.
• Team collaboration: Several people can work simultaneously on different child flows, without getting in each other's way inside the same huge flow.

Each child flow thus becomes a digital employee with a clearly outlined responsibility, reliably performing exactly one task, and can be tested, replaced, or extended individually as needed.

Step by step: creating a Child Flow

Step 1: Create solution and instant flow

Open an existing solution in Power Automate or create a new one. Within it, use New > Automation > Cloud flow > Instant to create a new flow and choose as trigger Manually trigger a flow. Only flows with this trigger, the Power Apps trigger, or the HTTP request trigger can later be called as a child flow.

Step 2: Define inputs

Using Add an input you determine which values the parent flow should pass to the child flow, for example a contact name or an order number. These inputs later appear in the parent flow as dynamic fields as soon as you select the child flow there.

Step 3: Build logic and return a result

Build the actual task within the child flow, whether that is a record in Dataverse, a calculation, or a match against a SharePoint list. At the end, you return the result via the action Respond to a Power App or flow or, in the premium connector, via Response back to the parent flow. Here too, any number of output values can be defined.

Step 4: Embed connections

If the child flow uses connectors other than built-in actions or Dataverse, on the properties page under Run only users you must select Use this connection instead of Provided by run-only user for every connection. Without this step, the call fails with an error message, because child flows only support embedded connections and currently cannot inherit connections from the parent flow.

Connecting the Parent Flow

In the parent flow, add the action Run a Child Flow from the connector Flows at the desired point and select the previously created child flow. Only flows that you have access to and that are in the same solution are shown. After selecting it, the input fields defined in the child flow appear, and after the call, the outputs are available as dynamic content for the following steps. The parent flow waits for the child flow to complete, for the full lifetime of the flow, meaning one year for built-in connections and Dataverse, or 30 days for all other connectors.

Practical example: determining approvers from SharePoint groups

An example from the Microsoft documentation shows the pattern well: a company needs approvals for project proposals, vacation requests, and expense reports, with the responsible people maintained in different SharePoint groups. Instead of rebuilding the query for the respective group in three separate flows, a single child flow is created that queries the matching SharePoint group and returns the list of approvers. The parent flow for project proposals, the one for vacation requests, and the one for expense reports then all call the same child flow and only pass which group is meant in each case. If the structure of the SharePoint groups changes later, you only need to adjust the child flow, and all three processes benefit automatically.

Limits and pitfalls

Child flows are not a set-and-forget solution and come with a few fixed rules you should know before building larger processes on top of them:

• Parent and child flow must be created directly in the same solution. If you later import an existing flow into a solution, the link can, according to Microsoft, lead to unexpected results.
• Connections currently cannot be passed from the parent to the child flow; every connection in the child flow must be embedded there.
• A child flow requires a manual, Power Apps, or HTTP request trigger; other triggers are not available for this purpose.
• With very many child flows across several solutions, it is also worth taking a look at licensing, for example at flow groups, which let you share a process license across multiple flows and their child flow executions.

You retain control over how granular you break things down: not every three-step task needs its own child flow, but as soon as a task appears in more than one place or a flow becomes confusing, splitting it up quickly pays off. Anyone who wants to modularize existing Power Automate processes with a clear structure and clean solution management will find support in NordFlux's Power Automate consulting.

Frequently asked questions

What is the difference between a Parent Flow and a Child Flow?

The parent flow can have any trigger and controls the overall process. The child flow takes on a single, clearly defined sub-task, receives inputs from the parent flow for this purpose, and returns a result at the end, similar to a function in a program.

Which triggers can a Child Flow use?

Only three triggers are suitable for child flows: Manually trigger a flow, the Power Apps trigger, and the trigger for incoming HTTP requests in the premium connector. A recurrence trigger or a SharePoint trigger does not work for this purpose.

Can I reuse an existing connection from the Parent Flow in the Child Flow?

No, connections currently cannot be passed from the parent to the child flow. Every connector used in the child flow must be stored there as an embedded connection via the run-only user setting.

How long does the Parent Flow wait for the Child Flow's response?

The parent flow pauses until the child flow has completed, for at most the lifetime of the flow. That is one year for flows with built-in connections and Dataverse, and 30 days for all other connectors.

Do the Parent Flow and Child Flow have to be in the same solution?

Yes, Microsoft explicitly recommends creating both directly in the same solution. Only this way are they automatically linked correctly when exported to another environment, without URLs having to be adjusted manually.

Sources: Microsoft Learn – Create child flows, Microsoft Learn – Create reusable code for child flows