Develop reusable logic by using child flows
Unit 3 closed with a problem that no amount of expression tuning, error handling, or retry policy solves: the allowance check, availability call, and routing logic in Contoso's equipment-provisioning flow looks nearly identical to logic duplicated across several other approval-style flows. This unit moves that logic out of each flow individually and into a single reusable child flow that multiple parent flows call. That way, Contoso maintains the logic once instead of copying it everywhere it's needed.
Separate what starts a flow from the logic it reuses
A child flow is a separate flow, nested inside and called by one or more parent flows. The two flows differ in how they start. A parent flow can have any trigger type: a Dataverse row-trigger, a schedule, an HTTP request, anything the scenario calls for.
A child flow, by contrast, always uses the Manually trigger a flow action, an instant trigger that doesn't fire on its own. Instead, the parent flow invokes it directly with a Run a Child Flow action, found under the Flows connector. It calls that action at whatever point in its own logic it needs that reusable behavior.
This relationship scales in both directions. A single parent flow can contain multiple child flows, each handling a distinct piece of reusable logic. More importantly for Contoso's situation, the same child flow can be called by multiple different parent flows. That second pattern is exactly what turns duplicated logic into shared logic: one child flow, several callers.
Decide whether duplication is worth extracting
Not every piece of logic that looks reusable deserves its own child flow. Two situations make extraction worth the effort. The first is logic duplicated across multiple flows, which is Contoso's case: the same approver-resolution steps show up in the equipment-provisioning flow and in other approval-style flows that also need to determine who should review a request.
The second is logic that's complex or long enough to clutter a single flow on its own. Guidance on structuring cloud flows notes that a flow built from dozens or hundreds of steps becomes difficult to navigate and maintain, even when none of those steps repeat elsewhere.
Extraction isn't free, though. Each child flow is a separate artifact someone maintains, tests, and keeps track of. A parent flow calling it also takes on a dependency it didn't have when the logic lived inline. That overhead only pays off when duplication costs more: if the approver-resolution logic changes, how many flows currently need the same edit made separately?
For Contoso, extracting that logic into one child flow replaces several copies of the same steps with one place to update when the resolution rules change. That one child flow is called by the equipment-provisioning flow and by the other approval-style flows that need it.
Guiding question: Think about a piece of logic repeated across more than one of your own flows. Does the cost of maintaining it separately in each flow outweigh the overhead of extracting it into a single child flow that each one calls?
Pass data between parent and child with inputs and outputs
A child flow doesn't have access to the parent flow's variables or trigger data unless the parent explicitly hands that data over. The child flow's Manually trigger a flow trigger defines one or more inputs: the specific pieces of data it needs from whichever parent calls it. For the approver-resolution child flow, that might mean an input for the request's department or category, whatever the logic needs to determine the right reviewer.
After the child flow's logic runs, it returns data to the caller through an explicit output. You set that output using a response action such as Respond to a Power App or flow or the premium Response action. You define as many outputs as the parent flow needs, such as the resolved approver's email address or ID.
When the parent flow reaches its Run a Child Flow action, it waits for the child flow to finish before continuing. The child flow's outputs then become available to the parent's later steps, the same way any other action's outputs would be. That wait has a ceiling, though: up to one year for built-in or Dataverse connections, and up to 30 days for all other connectors.
Design around how child flows share a solution and license capacity
Three practical constraints shape how parent and child flows work together in practice. A child flow must belong to a solution before the parent flow's Run a Child Flow action can list it as an option at all. A flow left outside a solution never appears in that picker, so this isn't optional.
Separately, Microsoft recommends building the parent flow and its child flows directly in that solution, rather than importing them in afterward. Flows brought together after the fact can produce unexpected results when you export and reimport them.
Connections work differently for child flows, too. A child flow only supports embedded connections (connections configured directly on that flow) and can't use a connection passed through from the parent's run-only user. If you leave a child flow's connections set to Provided by run-only user, Power Automate rejects it as a child workflow. Each connection a child flow uses needs to be set explicitly to its own embedded connection.
Licensing capacity doesn't pass between parent and child automatically, either. A flow group lets related flows share a single Process license's daily action capacity. But a child flow doesn't inherit that shared capacity just because its parent belongs to a group. If the approver-resolution child flow and the flows that call it need to draw from the same pool, add the child flow to the group explicitly, alongside each parent.
| Constraint | What it means for parent and child flows |
|---|---|
| Solution | Build both directly in the same solution; don't import a flow into a solution after the fact |
| Connections | Child flows use only embedded connections, never a connection passed through from the parent |
| Flow group capacity | A child flow doesn't inherit its parent's group; add it separately if they should share capacity |
A single reusable child flow now replaces several copies of the same approver-resolution logic across Contoso's flows. A change to how reviewers get assigned now only needs to happen in one place. That solves duplication, but it doesn't touch a different kind of fragility: what happens to any of these flows, parent or child, when the person who built and owns them leaves the company or their license lapses. That question shapes where flow ownership goes next.