Child flows

What it does

A child flow is a cloud flow called by another flow through the built-in Run a Child Flow action, with defined inputs and outputs. It gives you reusable, callable units of logic instead of one enormous flow, and the parent-child link survives solution export and import without any URL rewriting.

Key facts

Both parent and child must live in the same solution. Microsoft's guidance is to create them directly in that solution — importing an existing flow into one can produce unexpected results.
The child flow must use the Manually trigger a flow trigger. Inputs are defined on that trigger.
The child returns data through Respond to a Power App or flow (Power Apps connector) or Response (premium HTTP connector). Without one, the parent gets nothing back.
Any connector other than built-in actions and Dataverse must be set to embedded connections on the child's Run only users settings. Otherwise you get an error saying child workflows only support embedded connections.
Connections cannot be passed from parent to child. The child runs on its own embedded connections.
The parent waits for the child to finish — up to one year for flows using built-in connections and Dataverse, 30 days for everything else.
Child flows fall under the Medium performance profile for Power Platform request limits, alongside Power Apps triggered and manual flows.
Run a Child Flow is under the Flows connector on the Built-in tab, and only shows child flows you have access to that sit in a solution.

When to use / skip

Split into child flows when logic is genuinely reused across flows, when a single flow is heading towards the 500-action or eight-level nesting limits, or when a Switch has heavy branches and you'd rather skip a child flow than skip fifty individual actions. Keep it in one flow when the logic is used once, is short, and the process owner needs to read it end to end — chasing a business process across six flows in run history is miserable, and each call adds latency and requests. Reusable error handling is the one case where a child flow pays for itself almost immediately.

Configuration decisions

Which logic is genuinely reusable versus which just looks tidy split out.
Which account owns the child flow's embedded connections, since that identity performs the work for every caller.
The input and output contract, and how strictly you version it, because changing it breaks every parent at once.
Whether the child is called synchronously and waited on, or fired and forgotten with the parent continuing.
How errors surface — whether the child returns a status the parent inspects, or throws and lets the parent's catch scope handle it.

Gotchas

Embedded connections mean the child always runs as the connection owner, not the calling user. That's a security and audit conversation, not a technical detail, and it's how people accidentally grant broad access.
If the account owning the embedded connections leaves the organisation, every parent that calls the child breaks. Use a service account.
Change a child flow's inputs and every parent silently mismatches until you reopen and re-save each one.
Child flow run history lives on the child, not the parent. Troubleshooting means jumping between two run histories with no linking ID unless you passed one in.
The child must be manually triggerable, which also means anyone with access to it can run it directly with arbitrary inputs.
Flows imported into a solution rather than created there are the documented known issue. If a child behaves oddly after import, rebuild it in the solution.

Consultant notes

Sell child flows as reuse and maintainability, not as a way round the action limit. If the client only hears "limit", they'll split flows arbitrarily and make the estate worse.
Set up a service account for embedded connections at the start of the project. Retrofitting connection ownership across a dozen child flows is a bad week.
Pass a correlation ID into every child flow and log it at both ends. It is the only practical way to trace a run across parent and child.
Warn the client that the parent blocks while the child runs. For anything user-facing, that latency is real and it compounds with each nested call.
Child flows use the Medium performance profile, which may be better than the parent owner's — worth checking before you assume it's a licensing win either way.

Worth revisiting if connection passing from parent to child ever ships, or if the solution requirement changes.