A practical guide to keeping mission-critical flows running, no matter who owns them.
This guide explains what a service principal owned flow is, when to use one, and how to set it up. It is written for makers, admins, and anyone who supports automation in our environments. No prior knowledge of service principals is assumed.
| In one sentence A service principal lets a flow run as a secure application identity instead of a person, so the flow keeps working even when an individual leaves, changes roles, or loses a license. |
1. What is a service principal owned flow?
Every cloud flow has an owner. The owner is the identity the flow runs as, and it determines the connections, licenses, and permissions the flow relies on. By default, the owner is the person who built the flow.
A service principal is a non-human security identity that represents an application or service rather than a person. To use one in the Power Platform, you create an application user that represents the service principal. That application user can have connections shared with it and can own resources such as flows.
The difference is simple but important. A person-owned flow is tied to the lifecycle of that person. A service principal owned flow is tied to a stable application identity that the organization controls.
2. When should you use one?
Microsoft recommends running a flow under a service principal in the following situations.
- Mission-critical flows that serve departmental or enterprise-wide scenarios. Service principal ownership insulates the flow from the lifecycle of any single owner.
- Flows deployed through DevOps or ALM pipelines across Dev, Test, and Production environments.
- Any flow where the owner might leave the organization, change roles, or have a premium license unassigned while the flow still uses premium capabilities.
| Good to know A service principal application user is a non-interactive user with no user license. That means it is subject to non-licensed user request limits, which differ from the limits that apply to a licensed person. Plan for this when you move a high-volume flow. |
3. Use case: the offboarding break
The situation
Contoso runs an invoice approval flow that routes every vendor invoice over a threshold to the right approver, then writes the decision back to the finance system. It runs hundreds of times a day and the finance team depends on it. The flow was built by Jordan, a maker on the finance team, so it runs under Jordan’s identity and uses Jordan’s premium license and connections.
What goes wrong without a service principal
- Jordan accepts a new role in another department and is offboarded from the finance team.
- Jordan’s premium Power Automate license is reclaimed and reassigned during the offboarding cleanup.
- The flow, which depended on that license and Jordan’s connections, stops running.
- Invoice approvals stall. Finance notices only when vendors start chasing payments, and the team falls back to a manual workaround under time pressure.
The fix
Before any of that happens, the flow is placed in a solution and its owner is changed to a service principal application user that the platform team controls. Connections are configured against that application identity. Now the flow runs as the application, not as Jordan.
When Jordan leaves, nothing breaks. The flow keeps running because its identity, license entitlement, and connections are no longer tied to a single employee. The diagram below contrasts the two paths.
| The takeaway Decoupling ownership from a person turns a fragile, single-owner flow into a durable, governed asset. The higher the business impact of a flow, the stronger the case for a service principal owner. |
4. How to set it up
There are four steps to move a flow to a service principal owner. The connection-sharing step depends on whether the flow lives in a solution.
Step 1. Create the application user
Create a service principal application user that represents the Microsoft Entra ID service principal. This can be done through the Power Platform admin center or through the API.
Step 2. Share the connections (non-solution flows only)
For a non-solution flow, share the connections the flow uses with the service principal application user so it can run them. This step is not required for a solution flow, which is one more reason to keep important flows in solutions.
Step 3. Change the flow owner
In the Power Automate portal, open the flow, edit the Details section, and replace the Owner with the service principal application user. The flow then runs as that identity.
Step 4. Turn the flow on
Enable the flow so it is ready to run under the new owner.
| Important constraint A service principal application user can only be the sole owner of a flow. It cannot be added as a co-owner, and it will not appear in the Owners selection dialog. Plan ownership and co-management accordingly before you make the switch. |
5. Licensing and request limits
Because a service principal application user has no user license, two things follow. First, premium flows still need a license. Second, the flow draws on non-licensed request limits, which vary by context.
Licensing in short
- Premium service principal owned flows need a Power Automate Process or per-flow license.
- A flow is exempt from that requirement if it uses no premium connectors, or if it runs exclusively in the context of a Dynamics 365 application.
Request limits by context
The pooled request limits that apply depend on the context the flow runs in. The table summarizes the three cases.
| Context | Standard connectors | Premium connectors |
| Dynamics 365 apps | 500,000 base requests plus 5,000 per qualifying license, up to 10,000,000. | Same pool. Both standard and premium connectors are covered. |
| Power Apps | 25,000 base requests, no per-license accrual. | Needs a Process or per-flow license; up to 250,000 requests per flow. |
| Power Automate licenses | 25,000 base requests, no per-license accrual. | Needs a Process or per-flow license; up to 250,000 requests per flow. |
Figures reflect Microsoft documentation as of mid-2025. Always confirm current limits in the official docs before sizing a high-volume flow.
Tenant pool and performance
Service principal flows in the context of Dynamics applications can enable a Tenant pool setting on core business flows. With Tenant pool enabled, a flow uses the UnlimitedExtended performance profile and can scale to around ten million requests in 24 hours. With it disabled, the flow uses the Medium profile and a much lower ceiling.
- Flows created before October 20, 2023 have Tenant pool enabled by default.
- Flows created after that date have it disabled by default, but a maker can enable it at any time.
- Changes can take up to seven days to take effect. To apply immediately, edit and save the flow.
6. Quick reference checklist
Use this checklist when deciding on and configuring a service principal owned flow.
| Check | Why it matters |
| Is the flow mission-critical or pipeline-deployed? | If yes, a service principal owner is recommended. |
| Is the flow in a solution? | Solution flows skip connection sharing and are easier to manage through ALM. |
| Does the flow use premium connectors? | If yes, ensure a Process or per-flow license is available, unless it runs only in Dynamics 365 context. |
| Have you created the application user? | Create it in the admin center or via API before changing ownership. |
| Have you accounted for sole ownership? | A service principal cannot be a co-owner. Confirm no human co-owners are required. |
| Is the request volume understood? | Match the flow to the right context and Tenant pool setting for its throughput. |
| One known issue to watch If a flow owned by a service principal had Tenant pool enabled, importing that flow as a non-application user can throw an error. Keep import identities consistent with how the flow is owned. |
Source: Microsoft Learn, Support for service principal owned flows (Power Automate). This internal guide paraphrases and reorganizes that guidance for our teams. Verify licensing and limit figures against the live documentation before relying on them.