8.4 Reusable child flows & Microsoft Entra ID service principals

As a solution grows, the same fragments of logic — a standardized error-notification step, a validation routine, a call to a shared external API — tend to get copy-pasted into flow after flow. Child flows let a developer extract that logic once and call it from many parents, and service principals let flows and the components that call them authenticate as an application rather than as a specific interactive user. Both are core "reusable logic" and "integration security" topics on the exam.

Building a Child Flow

A flow becomes callable as a child flow when it uses the "Manually trigger a flow" instant trigger and defines one or more Input parameters on that trigger (text, number, boolean, or file). Those inputs become the parameters a caller must supply.

Calling a Child Flow

A parent flow invokes a child flow with the built-in Run a Child Flow action: the developer picks the child flow by name, and the designer surfaces fields for each of the child's declared Input parameters. The child flow's outputs from its final actions become available back in the parent through that action's dynamic content, letting the parent branch on, log, or forward whatever the child produced.

Requirements and constraints to know for the exam:

• The child flow must live in the same environment as the parent.
• The child flow must be turned on.
• The parent flow's owner needs run access to the child flow — either by owning it directly, by having it shared, or by both flows being packaged and deployed together in the same solution.

Why Use Child Flows

• Single source of truth — fixing or improving the shared logic (e.g., how an error notification is formatted) means editing one flow instead of every flow that needs it.
• Composability — a complex process can be broken into smaller, independently testable flows rather than one unmanageable canvas.
• ALM alignment — child and parent flows travel together in a solution with shared connection references and environment variables, so the same reuse benefits solutions provide for code apply to flow logic too.

Authenticating as an Application: Microsoft Entra ID Service Principals

Many integration scenarios need a flow — or an external system calling into Dataverse — to authenticate without a signed-in user. The mechanism is a Microsoft Entra ID (formerly Azure AD) app registration, which functions as a service principal: an identity that represents the application itself rather than a person.

Setting one up for a flow-to-Azure or system-to-Dataverse call typically involves:

1. Registering the application in Microsoft Entra ID.
2. Creating a client secret or certificate for it to authenticate with.
3. Granting it application permissions — as opposed to delegated permissions, which act on behalf of a signed-in user — on the target API, with admin consent where required.
4. For calls into Dataverse, adding the app registration as an Application User in the Dataverse security area and assigning it a security role that follows least privilege, the same principle applied to human users elsewhere in solution security design.

An Application User backed by a service principal is the standard way to let unattended workloads — including scheduled Azure Functions and external systems in integration scenarios — call the Dataverse Web API without consuming a full user license or depending on any individual's credentials, which would break the moment that person's password changed or their account was disabled.

Passing Complex Data to a Child Flow

The Manually trigger a flow trigger only accepts scalar Input parameter types — text, number, boolean, and file. When a parent flow needs to pass a structured object (a whole row's worth of fields, or an array of related records) to a child flow, the standard technique is to serialize that object with a Compose or string() expression into a single JSON-formatted text input, then have the child flow immediately run Parse JSON against a matching schema to reconstitute typed dynamic content from that text. This is the same expression toolkit covered for flow control — child flows do not get a separate object-passing mechanism, they reuse the JSON serialization pattern already used elsewhere in the flow.

Nesting and Solution Packaging

A child flow can itself call another child flow, layering reuse — a top-level orchestration flow might call a validation child flow, which in turn calls a shared logging child flow. There is no hard exam-relevant nesting limit to memorize, but each additional layer adds latency and makes failures harder to trace, so nesting depth should stay proportional to the actual duplication being eliminated. When child and parent flows are deployed together, they belong in the same solution so their connection references and environment variables move as a unit between Dev, Test, and Production — deploying a parent without its child (or vice versa) is a common ALM mistake that breaks the Run a Child Flow action in the target environment because the referenced flow simply doesn't exist there yet.