Power Automate child flows

A Power Automate flow with 50 actions, branches, loops, and error handling is unmaintainable. Child flows solve this — let one flow invoke another, encapsulating reusable logic in a separate flow that can be developed, tested, and maintained independently.

What a child flow is. A child flow is a normal Power Automate cloud flow with two characteristics:

• It's triggered by Power Apps or HTTP request (not by a Dataverse / SharePoint / scheduled trigger).
• It returns a value through a Response action (or in the case of HTTP, an HTTP response).

The "trigger by HTTP request" pattern is what enables child flows. A parent flow calls the child by sending an HTTP-style invocation; the child runs; the parent receives the response.

Why child flows.

• Reusability. A common pattern (e.g. "validate customer credit", "generate a quote PDF", "send a personalised email") used in many places gets implemented once as a child flow; many parent flows call it.

• Maintainability. Smaller flows are easier to understand, test, modify. Splitting a 100-action mega-flow into a parent and several child flows produces 5 flows of 20 actions each — substantially more tractable.

• Versioning. Child flows version independently; changes to the child flow don't require modifying every parent.

• Permissions and ownership. Different teams can own different child flows; integration is clean.

• Performance — sometimes. Each child flow invocation has overhead; for small operations the overhead exceeds the encapsulation benefit. Use for substantial logic blocks, not trivial ones.

Implementing a child flow.

1. Create the child flow. Trigger: "When an HTTP request is received" (or "PowerApps").

2. Define inputs. The HTTP trigger has a JSON schema for the request body; structure inputs as JSON properties.

3. Implement logic. Standard Power Automate actions.

4. Return output. End with a Response action returning JSON with the output data.

5. Save and copy the URL. The HTTP trigger generates a unique URL when saved; the parent flow uses this URL to call the child.

Calling a child flow from a parent.

1. In the parent flow, add an HTTP action.
2. Set method to POST.
3. URL to the child flow's invocation URL.
4. Body to the JSON payload matching the child's input schema.
5. Add a Parse JSON action to parse the child's response.
6. Use the parsed outputs in subsequent actions.

The pattern is functional but verbose. Microsoft has been improving the experience with native "Run a child flow" actions — but the underlying mechanism is HTTP.

Error handling.

• Child flow errors — if the child flow fails, the HTTP call returns an error status. The parent must handle.
• Retry policy — the HTTP action's retry configuration governs how many times to retry on child failure.
• Compensation — if a child flow performs side effects then fails, the parent may need to roll back. Design for it.

Performance considerations.

• Each child-flow invocation has HTTP overhead — typically hundreds of milliseconds.
• For high-frequency calls (a parent that calls a child 1000 times), the overhead dominates.
• For substantive child operations (each running for seconds or minutes), the overhead is negligible.

Limits.

• HTTP action requires premium connector — flows using HTTP need premium Power Automate licences.
• Loops over child invocations — Apply to Each calling a child for each record can hit timing / throughput issues at scale. Consider batching.
• Schema-evolution awareness — when a child flow's input or output schema changes, all parent flows need updating. Treat as API versioning.

Patterns and examples.

• Authentication helper — a child flow that, given a token request, returns a Bearer token. Parent flows call it before making external API calls.
• Audit log helper — a child flow that records an entry in the audit log Dataverse table. Many parent flows call it to log significant events.
• PDF generation helper — a child flow that, given record data, generates and stores a PDF. Many parent flows trigger document generation.
• Notification orchestrator — a child flow that handles multi-channel notification (email + SMS + Teams) based on user preferences. Parent flows just say "notify".

Solution and ALM. Child flows live in solutions like any flow. Reference between solutions:

• Same solution — child and parent in the same solution; deploy together.
• Different solutions — child flow in a "shared services" solution, parents in different feature solutions. The parent flows reference the child by ID.

For ALM, the parent's HTTP URL is environment-specific; use environment variables to abstract the URL.

Common pitfalls.

• Child flow URL hard-coded — different environments have different URLs; manual update required at each deploy. Use environment variables.
• Synchronous vs async confusion — child flow runs synchronously to the HTTP call; if it's long-running, the parent waits. For long operations, consider passing a callback URL for asynchronous notification.
• Permission propagation — the child flow runs as its owner's identity, not the parent's. If the child needs the parent's user context, pass relevant context as input.

Operational reality. For Power Automate work that grows beyond simple flows, child flows are the maintainability lever. Adopt them early; refactor existing complex flows incrementally as opportunities arise.