Overview
Child flows allow you to break complex automation into smaller, reusable components that can be called from multiple parent flows. Using the “Run a flow built with Power Automate” action, parent flows can trigger child flows, pass parameters, receive return values, and orchestrate multi-step processes across different flows for better maintainability and reusability.
Prerequisites
- Power Automate cloud flow experience
- Understanding of triggers and actions
- Familiarity with variables and dynamic content
- Basic knowledge of flow design patterns
What Are Child Flows?
Child flows are cloud flows that are created to be triggered by other flows (parent flows). Instead of building one massive flow with hundreds of actions, you can break your automation into logical components—each component is a child flow that can be called when needed.
Common use cases for child flows:
- Reusable error notification logic called from multiple flows
- Prevent duplicated Power Automate flows
- Run a flow from another account
- Logging and audit trail creation across workflows
- Complex approval routing that multiple processes share
- Data transformation or validation used by several flows
In this post we will show you how to create and use a child flow.
Benefits of child flows:
- Reusability – Write once, call from multiple parent flows
- Maintainability – Update logic in one place rather than editing dozens of flows
- Organisation – Break complex processes into understandable, focused components
- Testing – Test individual components independently before integrating
- Performance – Parallel child flow execution for faster processing
Parent flows call child flows synchronously—the parent flow waits for the child flow to complete before continuing. This ensures you receive return values from the child flow and can use them in subsequent actions. For asynchronous execution where the parent doesn't wait, trigger the child flow using HTTP request triggers instead.
Building a Child Flow from Scratch
For this example we are going to create a child flow with a name using a Child flow, therefore the user that runs the flow doesn't need read and permissions for it.
A button triggered flow will call the child flow (which checks for duplicate rows). Imagine the user that runs the flow doesn't have a SharePoint licence where the duplicate checks need to happen. Instead of adding multiple things being owned by a user, the child flow is owned by an admin who has all the appropriate things running within the flow.
Creating the child flow:
Go to Power Automate → Create → Automated cloud flow (or Instant if testing with manual trigger).
This is the trigger that indicates this flow is designed to be called by parent flows. The "(V2)" version supports parameters and response values.
Click "+ Add an input" to define what parameters the parent flow will send. Choose the data type (Text, Number, Yes/No, File, Email, Array).
Add actions that use the input parameters. Access them from dynamic content under "When a flow is run from another flow".
At the end of your child flow, add this action to return values back to the parent flow. Add outputs for each value you want to return.
We will then add our actions and inputs but first we'll look at what parameters we have (and what outputs) as it'll make it easier for the parent flow.
For the child flow we are going to pass it an email address and company name to check if there are any duplicate contacts.
Example child flow structure:
- Trigger: When a flow is run from another flow (with Email and CompanyName inputs)
- Get items: Query SharePoint for contacts matching email or company
- Condition: Check if duplicates exist (list length > 0)
- Respond to Power App or flow: Return "DuplicateFound" (Yes/No) and "DuplicateCount" (Number)
Always use "When a flow is run from another flow (V2)" for new child flows. The V2 version supports typed parameters (Text, Number, Boolean, etc.) and structured responses. The V1 version only supports JSON payloads, making it harder to work with and prone to errors. V2 provides a much better experience in both child and parent flows.
Triggering a Child Flow from the Parent Flow
To call the child flow we will now trigger it from the manual button flow and use parameters we have set (company name and email from the parent flow).
Search for "Run a flow built with Power Automate" in the actions list. This is the action that triggers child flows.
Power Automate shows all flows that have the "When a flow is run from another flow" trigger. Select the child flow you created.
The action automatically displays fields for each parameter defined in the child flow. Provide values using dynamic content, variables, or static text.
Example parent flow calling child:
// Trigger: Manually trigger a flow
// Input: Email (text), CompanyName (text)
// Action: Run a flow built with Power Automate
Flow: Check for Duplicate Contacts
Email: triggerBody()?['text']
CompanyName: triggerBody()?['text_1']
When the parent flow runs, it calls the child flow synchronously, waits for the child to complete, then continues with the next action. The parent flow can access return values from the child flow's "Respond to a Power App or flow" action.
Accessing child flow return values:
After the "Run a flow built with Power Automate" action, the child flow's outputs appear in dynamic content. Use them in subsequent actions:
// Action: Condition
// Check if child flow found duplicates
Condition: outputs('Run_a_flow_built_with_Power_Automate')?['body/DuplicateFound']
Equals: true
If yes: Send notification about duplicate
If no: Proceed with creating new contact
Rename your "Run a flow built with Power Automate" actions descriptively (e.g., "Check for Duplicates" instead of "Run a flow built with Power Automate"). This makes outputs easier to find in dynamic content and makes your flow more readable. The output reference becomes outputs('Check_for_Duplicates') instead of outputs('Run_a_flow_built_with_Power_Automate').
Sending Data Back to the Parent Flow
Finally we will use the 'Respond to a Power App or Flow' action.
Once the child flow has finished its task (validation, data lookup, calculation), it can send results back to the parent flow using the "Respond to a Power App or flow" action. This is how the parent flow knows what the child flow discovered or calculated.
This must be the final action in the child flow. Any actions after this will not execute.
Choose the data type (Text, Number, Yes/No, Array, etc.) and provide a name for the output.
Reference variables, action outputs, or calculations from earlier in the child flow.
Example response outputs:
| Output Name | Type | Value |
|---|---|---|
| DuplicateFound | Yes/No | variables('varHasDuplicates') |
| DuplicateCount | Number | length(outputs('Get_items')?['body/value']) |
| MatchingRecordIDs | Array | outputs('Select')?['body'] |
| ErrorMessage | Text | if(equals(variables('varError'),''),'Success',variables('varError')) |
Accessing these outputs in the parent flow:
// After "Run a flow built with Power Automate" action
// Get boolean output
outputs('Check_for_Duplicates')?['body/DuplicateFound']
// Get number output
outputs('Check_for_Duplicates')?['body/DuplicateCount']
// Get array output
outputs('Check_for_Duplicates')?['body/MatchingRecordIDs']
// Get text output
outputs('Check_for_Duplicates')?['body/ErrorMessage']
Using outputs in conditions:
// Condition to check duplicate status
Condition: outputs('Check_for_Duplicates')?['body/DuplicateFound']
Equals: true
// Condition to check count
Condition: outputs('Check_for_Duplicates')?['body/DuplicateCount']
is greater than: 0
// Using in email subject
concat('Found ', outputs('Check_for_Duplicates')?['body/DuplicateCount'], ' duplicates')
Handling multiple response scenarios:
Instead of using Respond to specify an answer of yes or no (in the case of the DuplicateFound output), you could put the "Respond to a Power App or flow" action in both branches to return different success/failure messages:
// In child flow Condition "If yes" branch (duplicates found):
Respond to a Power App or flow
DuplicateFound: true
DuplicateCount: length(outputs('Get_items')?['body/value'])
Message: "Duplicates detected"
// In child flow "If no" branch (no duplicates):
Respond to a Power App or flow
DuplicateFound: false
DuplicateCount: 0
Message: "No duplicates found"
The "Respond to a Power App or flow" action must be the last action executed in the child flow. If you have parallel branches or multiple paths, ensure each path ends with a response action. If the child flow terminates without sending a response, the parent flow will wait indefinitely until timeout (typically 30 days for cloud flows, causing the parent to fail).
Complex Orchestration Scenarios
Beyond simple parent-child relationships, you can build sophisticated workflow orchestration using multiple child flows, conditional calling, and parallel execution.
Calling multiple child flows in sequence:
// Parent flow orchestration
1. Run child flow: Validate Input Data
Inputs: Email, CompanyName
Outputs: IsValid, ValidationMessage
2. Condition: Check if IsValid = true
If yes:
3. Run child flow: Check for Duplicates
Inputs: Email, CompanyName
Outputs: DuplicateFound, DuplicateCount
4. Condition: Check if DuplicateFound = false
If yes:
5. Run child flow: Create Contact Record
Inputs: Email, CompanyName, etc.
Outputs: ContactID, Success
6. Run child flow: Send Welcome Email
Inputs: ContactID, Email
Outputs: EmailSent
This pattern chains child flows together, with each subsequent child flow only executing if previous validations pass.
Parallel child flow execution:
Use parallel branches to call multiple child flows simultaneously for faster processing:
// Parent flow with parallel branches
Branch 1:
Run child flow: Process Invoice Data
Branch 2:
Run child flow: Update Inventory System
Branch 3:
Run child flow: Send Customer Notification
// All three child flows run simultaneously
// Parent continues after all branches complete
Conditional child flow calling:
// Only call child flow if certain conditions are met
Condition: Amount is greater than 5000
If yes:
Run child flow: Request Manager Approval
Inputs: Amount, RequestID
Outputs: Approved, ApproverEmail
If no:
Run child flow: Auto-Approve Request
Inputs: RequestID
Outputs: ApprovedDate
Error handling with child flows:
// Scope action containing child flow call
Scope: Try Create Contact
Run child flow: Create Contact Record
Inputs: ContactData
Outputs: ContactID, Success
// Configure run after on error scope
Scope: Catch Error (Configure run after: has failed)
Run child flow: Log Error
Inputs: ErrorMessage, FlowName, Timestamp
Outputs: LogID
Run child flow: Send Admin Alert
Inputs: ErrorDetails
Outputs: AlertSent
Reusable child flow for multiple parent flows:
One child flow can be called by many different parent flows. For example, a "Send Notification Email" child flow could be used by:
- Invoice approval flow
- Task assignment flow
- Document upload flow
- Schedule reminder flow
Each parent passes different parameters (recipient, subject, body), but the email sending logic exists only in the child flow. Update the email template once, and all parent flows benefit.
Document your child flow's purpose, expected inputs, and output values in the flow description. When other team members (or future you) need to call this child flow, the description serves as documentation explaining what parameters to pass and what return values to expect, saving time debugging parameter mismatches.
Child Flow Design Best Practices
Naming conventions:
- Prefix child flows with "[Child]" or "[Reusable]" to distinguish them from standard flows
- Use descriptive names: "[Child] Check for Duplicate Contacts" not "Child Flow 1"
- Document input and output parameters in the flow description
Parameter design:
- Keep parameters focused—pass only what the child flow needs
- Use typed parameters (Number, Boolean, etc.) rather than passing everything as Text
- Provide default values where appropriate to handle optional parameters
- Validate input parameters at the start of the child flow before processing
Error handling:
- Always include a "Respond to a Power App or flow" action in every execution path
- Return error indicators (Success: true/false, ErrorMessage: text) so parents can react appropriately
- Use Configure run after to handle failures and still send responses
- Consider adding a "Run child flow" inside a Scope with error handling configured
Performance considerations:
- Child flows add execution time—each call is a separate flow run with startup overhead
- For simple logic used once, inline actions may be faster than child flows
- Use parallel branches when calling multiple independent child flows
- Monitor flow runs—excessive child flow calls can impact API limits
Common issues and solutions:
| Issue | Cause | Solution |
|---|---|---|
| Parent flow times out waiting for child | Child flow has no response action or response is in unreachable branch | Ensure every execution path in child flow ends with "Respond to Power App or flow" |
| Cannot find child flow in dropdown | Child flow doesn't have "When a flow is run from another flow" trigger | Recreate child flow with correct trigger type |
| Child flow outputs not available in parent | Child flow has no "Respond to Power App or flow" action | Add response action with outputs at end of child flow |
| Parameter type mismatch errors | Passing text to number parameter or vice versa | Use Value() to convert text to number or String() to convert number to text |
| Child flow runs but parent doesn't continue | Child flow hasn't sent response yet (long running actions) | Parent waits for response—child flow must complete and respond |
Child flows run under the credentials of the child flow owner, not the parent flow owner. If a child flow accesses SharePoint or Dataverse, the child flow owner needs appropriate licences and permissions. This is useful for allowing users without premium connectors to trigger flows that use premium connectors—the child flow owner has the premium licence, not the parent flow triggerer.
Next Steps
You now understand how to create child flows, call them from parent flows, pass parameters, and receive return values. Child flows enable modular, reusable automation architecture that's easier to maintain and scale across your organisation.
Expand your flow orchestration capabilities by exploring:
- HTTP request triggers – Alternative to "When a flow is run from another flow" for asynchronous child flow execution where the parent doesn't wait
- Scope actions – Group related actions and apply error handling to entire sections including child flow calls
- Solution-aware flows – Package child flows with parent flows in solutions for easier deployment across environments
- Flow approvals in child flows – Centralise approval logic in reusable child flows called by multiple parent workflows
- Concurrent() function – Execute multiple child flow calls in parallel for improved performance
- Environment variables – Use environment variables in child flows to make them configurable across dev/test/prod environments
- Child flow versioning – Strategies for updating child flows without breaking parent flows that depend on them
The Microsoft Power Automate documentation on child flows provides additional examples, best practices, and guidance on advanced orchestration patterns including error handling and retry logic.
Need this built for your business?
We design and build production-grade Power Platform solutions for FM, Construction and Manufacturing businesses.
Book a Discovery Call →