What it does

A service principal is a non-human identity in Microsoft Entra. Represent it in Power Platform as a Dataverse application user and it can own and run cloud flows, hold shared connections, and survive every staff change the client throws at it.

Key facts

• You create the application user in the Power Platform admin centre or through the API, then set it as the flow's Owner on the flow details page.
• For a non-solution flow, connections must be shared with the application user first. For a solution flow that step isn't required.
• A service principal application user can't be a co-owner. It won't even appear in the Owners dialog — only in the Owner field.
• It's a non-interactive user with no user licence, so it falls under non-licensed user request limits.
• Premium service principal-owned flows need a Power Automate Process or per-flow licence. Flows using only standard connectors, or running purely in the context of a Dynamics 365 app, are exempt.
• Request allocations differ by context. Flows in Dynamics 365 context draw on a tenant pool with a base allocation plus per-licence accrual up to a documented ceiling; Power Apps context and Power Automate-licensed tenants get a smaller standard-connector base, with premium flows needing a Process or per-flow licence.
• The Tenant pool capacity toggle on the flow details page controls whether a Dynamics-context flow draws on the larger tenant pool and gets the UnlimitedExtended performance profile, or stays on the Medium profile with a lower ceiling.
• Flows created before 20 October 2023 have tenant pool on by default; those created after have it off. Toggling it can take up to seven days to apply unless you edit and save the flow to force it.
• Microsoft's own recommendation is service principal ownership for mission-critical departmental or enterprise flows, and for anything deployed through DevOps pipelines across Dev/Test/Prod.

When to use / skip

Use it for anything the business would notice failing. A named-account flow is a dependency on one person's employment, one person's licence assignment, and one person's willingness to re-authenticate a connection at 7am. Skip it for genuinely personal productivity flows, where the overhead of an app registration and a licence conversation buys nothing. The dividing line is simple: if the flow appearing on a status report would be embarrassing, it shouldn't be owned by a person.

Configuration decisions

• One service principal per solution or workload, versus one shared across the estate. Shared is easier to manage and worse to audit.
• Which Dataverse security roles the application user gets, since it inherits nothing by default and over-granting here is invisible.
• Whether flows are solution-aware, which removes the connection-sharing step and makes ownership assignment much cleaner.
• Whether tenant pool capacity is on for Dynamics-context flows, weighing the higher ceiling against one bad flow consuming the tenant's shared allocation.
• How the app registration's secrets or certificates are stored and rotated, and who owns that rotation.

Gotchas

• No co-ownership means no shared editing under the service principal. Humans still need their own access to maintain the flow, which people forget when they hand ownership over and lock themselves out of the properties.
• Non-licensed user request limits are a different and generally tighter regime than a licensed user's. A flow that ran happily under a named account can start throttling after transfer.
• There's a documented known issue: if a service principal-owned flow with tenant pool enabled was turned on, importing that flow as a non-application user throws an error.
• Connections still have to exist and be shared for non-solution flows. Transferring ownership without doing that gives you a flow that owns nothing it needs.
• The secret expiring is the new single point of failure. You've traded a leaver risk for a credential-rotation risk, which is better but only if someone diarised it.

Consultant notes

• Raise this in the first architecture session, not at go-live. Creating an app registration usually needs Entra permissions the project team doesn't hold, and that approval takes longer than the build.
• Frame the pitch as continuity, not security. "This keeps running when Dave leaves" lands with a sponsor; "non-interactive identity" does not.
• Check the licence position before promising it. Premium connectors under a service principal need Process or per-flow licensing and that's a real line item.
• Document the app registration ID, its secret expiry date and the Dataverse roles it holds in the client's runbook. This is the single most commonly undocumented dependency in a Power Platform estate.

---

Worth revisiting if co-ownership by service principals ever ships, or if the request limit tiers change again.