For a 40-person CPA practice, should Power Automate flows be owned by a staff member with a co-owner, a service account, or a service principal?
Match the identity to how critical the flow is. A named staff owner with a maintenance co-owner suits small, user-context flows. A dedicated, correctly licensed service account suits flows whose connectors need a user sign-in. A service principal application user suits practice-wide, mission-critical flows. None of the three, on its own, replaces a departed employee's connections, so plan connection credentials separately from ownership.
The three options, side by side
- Named staff owner plus a maintenance co-owner fits when a small workflow runs in one person's context and accountable people maintain it; avoid it when you expect co-ownership to keep a leaver's connections working, because Microsoft says actions using those connections can fail and co-owners cannot change credentials in connections another owner created.
- A dedicated user account run as a service account fits when connectors need a user sign-in and the practice can administer that account, its access and its licensing apart from any employee; avoid it when the plan involves a shared staff password or assumes one account removes licensing obligations, since Microsoft warns the account must be licensed correctly to avoid multiplexing.
- A service principal application user as primary owner, with named human maintainers, fits when a practice-wide workflow such as client intake or deadline routing must not follow any employee's lifecycle; avoid it when you assume every connector now authenticates as the application or that application ownership is license-free.
Which one we'd pick, and what would change it
For most 40-person CPA practices, a named owner with a narrowly chosen maintenance co-owner is the right starting point for everyday flows, with a service principal reserved for the handful of flows that touch every client engagement, such as intake or filing-deadline reminders. The condition that changes the answer is connector authentication: if a critical flow depends on connectors that only accept a user sign-in, a properly licensed service account becomes the practical primary identity instead.
Leaving flow ownership tied to one employee has a concrete cost. When that person leaves, a client-intake flow can sit with nobody able to edit it, and a deadline-routing flow can keep running while the specific actions that used the leaver's connections quietly fail. In a CPA practice that means intake requests and filing reminders that never reach anyone, discovered only when a client or a deadline surfaces the gap.
Ownership and connections are two separate problems
Microsoft's sharing documentation, last updated 08/19/2026, states that if a shared flow still has an active owner, the flow continues to run. The same page warns that if the flow uses active or embedded connections belonging to a user who left the organization, those specific actions might fail, and it tells admins to update the credentials for those connections when removing an owner.
Run-only users are not replacement maintainers. Granting someone permission to trigger a flow does not let them repair its connections or edit its logic after the builder leaves, so a run-only list should never be counted as succession planning.
What Microsoft's documentation says about each identity
The ownership-transfer page, last updated 09/25/2026, says a non-solution cloud flow's owner cannot be changed in place because the owner is part of the flow identity. For solution-aware flows, the owner can be changed to an individual (not a distribution list) or to a user account used as a service account, and Microsoft adds that a service account must be licensed correctly to avoid multiplexing.
The service principal support page, last updated 08/15/2026, requires the owner to be an application user and states that a service principal application user cannot be made a co-owner of a flow. Human maintainers therefore need their own access path alongside the application owner, not a co-ownership slot next to it.
Premium flows owned by a service principal application user need one of three entitlements, per the same page: a Power Automate Process or per-flow license assigned to the flow, membership in a flow group that has a Process license assigned, or a designated licensed user whose Power Automate entitlement the flow runs under. Check which applies to your tenant, and the request limits that come with it, before choosing this route.
None of these documentation updates announce a launch, retirement, price change or migration deadline. The dates above are the pages' last-updated dates, and the ownership question is an evergreen one worth settling before someone gives notice.
A safe handover sequence for an existing flow
- Inventory each flow: primary owner, co-owners, run-only users, every trigger and action connection and whose credentials it uses, the licensing entitlement it relies on, and whether it lives in a solution.
- For non-solution flows, plan either the documented conversion into a solution or a rebuilt flow, because the owner cannot be changed in place.
- If you build a new instance, disable or gate the old trigger before enabling the new one so the same client case is not processed twice.
- Assign the chosen primary identity, then replace any connection that still uses a departing or departed employee's credentials.
- Confirm the licensing entitlement for that identity and the flow, including premium connector requirements and request limits.
- Test the replacement connections and one representative failure path using non-client test data before relying on the handover in live work.
Chrysis Networks helps practices run this inventory and handover as part of its automation work, so intake and deadline flows keep a maintainer when staff change.
Frequently asked
Does adding a co-owner keep a flow working after the builder leaves?
The flow keeps running while an active owner remains, but actions that used the leaver's connections can still fail until someone updates those credentials.
Can a service principal be a co-owner of a Power Automate flow?
No. Microsoft states a service principal application user cannot be made a co-owner; it can be the primary owner, with humans maintaining access separately.
Can we just change the owner of an existing flow?
Only for solution-aware flows. A non-solution cloud flow's owner cannot be changed in place, so convert it to a solution or rebuild it.
Does a service principal remove the need for Power Automate licenses?
No. Premium flows it owns need a Process or per-flow license, Process-licensed flow group membership, or a designated licensed user.
Is a shared staff login an acceptable service account?
No. A service account should be a dedicated, administered and correctly licensed account, not a password passed between employees.