Reassign Power Automate Flow Owner When a User Leaves

To reassign a Power Automate flow owner after someone leaves your organization and keep the automation running, you change ownership in Power Automate, review connections, check licensing, and run tests so triggers still fire. This checklist gives you repeatable steps every time a flow owner departs.

Before you start

A cloud flow owner has full control over editing, managing, sharing, and deleting a flow, and the creator is automatically set as the owner when the flow is first built, as described in Microsoft’s guidance on changing the owner of a cloud flow. Ownership determines who can configure permissions and monitor run history, so you should reassign it when a flow owner leaves or changes roles.

You can change the owner directly only for solution-aware flows. Non-solution flows cannot have their owner changed in place. If your environment has Dataverse, add the flow to a solution so you can change ownership; otherwise you must recreate the flow with a new owner.

Microsoft documents in its article on limits of automated, scheduled, and instant flows that a cloud flow uses the plan of its owner and that automated or scheduled flows run under the license of the owner, while manual flows run under the license of the user who runs them. Environment-wide management for Power Automate resources is performed through the Power Platform admin center, as part of the broader Power Platform documentation.

How do I reassign a Power Automate flow owner when someone leaves?

To reassign a Power Automate flow owner when someone leaves, first confirm whether the flow is solution-aware. Then change the primary owner, handle any non-solution flows by adding them to a solution or recreating them, and decide whether to move ownership to a service principal application user.

1. Confirm whether the flow is solution-aware and change owner

1. Sign in to Power Automate and select My flows.
2. If the flow appears under Solutions, open the solution that references the flow, as in changing the owner of a cloud flow.
3. On the flow details page, select Edit, then in Primary owner remove the current owner and enter the email address of the new owner.
4. If the flow does not appear under Solutions, treat it as a non-solution flow for ownership purposes.

2. Handle non-solution flows

1. If Dataverse is available in the environment, add the flow to a solution and then change ownership by using the steps above.
2. If Dataverse is not available, recreate the flow as a new non-solution cloud flow by using export or import, Save as, or Send a copy, so the new owner is set on the new flow identity.

3. Optionally change ownership to a service principal application user

Microsoft supports flows owned and run by a service principal application user, a non-human identity representing an application or service that gives more stable ownership.

1. Create a service principal application user.
2. Share the required connections with that application user.
3. In the flow’s Details edit dialog, replace the Owner with the service principal application user and turn on the flow.

You cannot make a service principal application user a co-owner of a flow, and you will not find that user in the Owners edit dialog.

Review and fix flow connections after ownership changes

Changing the owner does not fix broken connections; you also need to ensure the flow’s connections work under accounts that will continue authenticating. Power Automate uses connections to access data in services like SharePoint, Microsoft 365, and SQL, and you manage them under Data > Connections, as described in Manage connections in Power Automate.

1. Identify connections used by the flow

1. In Power Automate, go to Data > Connections.
2. Select a connection and choose the ellipsis (…) then Details.
3. In the details pane, select Flows using this connection to see which flows rely on that connection and could fail if the underlying account is disabled.

2. Fix or update connections that are failing

Authentication failures are a common reason cloud flows fail; error messages often contain Unauthorized or error codes 401 or 403. Microsoft explains how to fix these errors and resubmit runs in its article on troubleshooting a cloud flow.

1. From the flow’s run history, open a failed run.
2. In the error pane, select View connections and find the connection with the authentication error.
3. Select Fix connection and verify or update the credentials, then resubmit the run.

3. Ensure connections are shared correctly for service principal owners

When a flow owner is a service principal application user, Microsoft documents that you must share the flow’s connections with that application user so the flow can run successfully in its guidance on changing the owner of a cloud flow. If the flow uses an on-premises data gateway, ensure any new connection created for the new owner or service principal uses the correct gateway and credentials.

Check licensing and limits after changing the owner

Ownership changes affect licensing and request limits. Microsoft states that a cloud flow uses the plan of its owner and that if a user has multiple plans, the flow uses the performance profile of the higher plan in its article on limits of automated, scheduled, and instant flows.

1. Verify which license plan the flow now uses

After you change the owner, the plan section of the flow shows whose license plan it uses. For automated and scheduled flows, the flow runs under the license of the new owner and uses their Power Platform request limits. Microsoft notes in its guidance on changing the owner of a cloud flow that this change can take up to seven days unless you edit and save the flow, which forces immediate use of the new owner’s license. Manual flows continue to run under the license of the user who triggers the flow.

2. Check for premium feature warnings

Microsoft documents that if you change ownership to a new owner who does not have a premium license and the flow uses premium features, a warning appears. The flow can still be assigned to the new owner but runs for 30 days, giving time to purchase a license; if the new owner still lacks a premium license after that grace period, Power Automate turns off the flow.

3. Consider limits when using service principal ownership

Service principal application users are non-interactive and cannot have a user license associated with them. They are subject to non-licensed user limits and have special licensing and request limit implications. Microsoft lists options to address these implications, including Pay As You Go, associating the flow to an app, or using a Power Automate Process license that can be shared across multiple flows through a flow group.

Confirm the flow still works after reassignment

After changing ownership and reviewing connections and licensing, confirm that the flow continues to run as expected. Microsoft documents that owners can use the run history view to identify specific flow runs by Start, Duration, and Status and then drill into errors in its article on troubleshooting a cloud flow.

1. Use run history to validate a recent run

1. In Power Automate, select My flows and then the flow.
2. In the 28-day run history section, open a recent run.
3. Expand the run details and look for any step with a red exclamation icon.
4. Open the failed step and review the error message in the right pane.

2. Configure run history columns for easier checks

Flow owners can configure the list of columns displayed on the run history page so that key trigger outputs are visible by default. On the flow details page, select Edit columns, choose the columns you want to see, and then select Save.

3. Watch for flows turning off due to errors

Microsoft documents that flows with errors that continue for 14 days can be turned off by the system and that flows without trigger activity for 90 days might be turned off, with owners notified 30 days before suspension, in its article on limits of automated, scheduled, and instant flows. After ownership changes, monitor for repeated failures so you can correct them before the suspension window.

Use admin tools to find other flows at risk

Once you have fixed ownership for one flow, you likely need to find other flows where the owner has left or where connections might be problematic. Environment-wide administration is done in the Power Platform admin center described in the Microsoft Power Platform documentation. Microsoft shows patterns for admins to use List environments as admin and Get connections as admin to inventory connections in Manage connections in Power Automate, and non-admins can use List my connections to see which apps and flows use each connection.

For a broader governance view of what breaks when owners leave and how to design ownership that lasts, see Power Automate Governance for SharePoint: What Breaks When Owners Leave. If you need help designing durable ownership and licensing patterns across environments, the consulting offering on the Power Platform Solutions page can support that work.