Power Automate flows can stop after an employee leaves because their connections, permissions or licences still depend on that person’s account. Changing its owner can restore management responsibility, but it doesn’t automatically replace the credentials used by Outlook, SharePoint, Dataverse or another connected service.
The recovery method also depends on whether the flow is solution-aware, meaning it belongs to a Power Platform solution. Start by separating ownership, authentication and licensing before changing the configuration.
Key Takeaways
- A new owner gains management responsibility, but the change doesn’t replace the flow’s connections, permissions or licence.
- A solution-aware cloud flow can have its primary owner changed in place by an administrator or someone with the required Dataverse privilege.
- A non-solution-aware flow can’t have its primary owner transferred in place. A copied flow has a new ID, so dependent apps and systems may need updating.
- Use an authorised operating identity, retain appropriate authentication requirements and test the full business process before retiring the original flow.
What changes when a Power Automate flow owner leaves?
An employee’s departure doesn’t necessarily stop every automation immediately. The failure depends on what happens to their account, its connections and the licences supporting it.
Management responsibility determines who can manage the automation
The owner is responsible for the automation, whilst co-owners can maintain it and review its configuration. Without an available owner, orphaned flows can result, even if existing connections temporarily continue working.
Adding another owner provides management access. It doesn’t prove that the automation can operate independently of the departed employee.
Include automation management responsibility in the wider Microsoft 365 leaver checklist, alongside account access, retained files and shared resources. Leaving the account enabled solely to preserve undocumented automation retains unnecessary access.
Connections determine how actions authenticate
A connection holds the authentication context used to access another service. An Outlook action can therefore remain dependent on the previous owner’s account after somebody else becomes responsible for the automation.
Review the first failed action, its connection and the identity behind it. For authentication failures, Microsoft 365 sign-in log analysis can help distinguish account restrictions, authentication requirements and Conditional Access failures.
An additional maintainer can’t simply edit another owner’s connection credentials. Replace affected connections with appropriately authorised ones.
Choose the recovery method by flow type
Record the flow ID, environment, connection identities, current managers and solution membership before making changes. Include details that distinguish development, test and production automations, since similarly named automations can exist in each.
Use this distinction to choose the recovery route.
| Automation situation | Appropriate route | Important limitation |
|---|---|---|
| Solution-aware automation with management access | Change its primary manager in place | Connections and licensing still need review |
| Non-solution-aware automation with a maintainer | Add it to a solution where supported, or create a replacement | A copy has a different ID |
| Automation with no available manager | Restore administrative management access first | Management recovery doesn’t repair credentials |
| Power App that depends on the automation | Review the app and automation separately | Changing app management responsibility doesn’t transfer the automation |
The main decision is whether an in-place transfer is supported. Don’t start with a copying workaround when a solution-aware automation can retain its identity.
Record the existing state before editing. An export and configuration record help preserve the recovery position, although they don’t preserve working credentials.
Share the flow and transfer supported ownership
Sharing a flow gives another person management access. Changing its primary owner is a separate operation, supported in place for solution-aware cloud flows.
Add a co-owner through Power Automate
Where an existing owner or authorised maintainer has access, use the sharing controls:
- Open Power Automate, select the correct environment and go to My flows.
- Select the item, choose Share, and add the intended person or authorised group.
- Confirm that the new account can open it and review its configuration.
It appears under Shared with me in Power Automate.
The administrative inventory is separate: Power Platform admin center > Manage > Environments > [environment] > Resources > Flows. Use its Owners column to identify responsibility. This inventory is separate from the maker portal’s shared-item view.
Change a solution-aware flow’s primary owner
Microsoft’s cloud flow ownership guidance explains how to change owner in place for a solution-aware cloud flow:
- Open the solution-aware item in Power Automate.
- In Details, select Edit.
- Remove the existing entry under Primary owner and enter the new owner’s email address.
- Save the change.
The acting owner or co-owner must also be an administrator or hold the Dataverse prvChangeOwnerIdOfWorkflow privilege. Co-ownership alone doesn’t provide that permission.
After the change, the previous owner and new primary owner remain co-owners. Review the previous owner’s remaining access separately, then reassign connections and test the automation under its intended operating identity.
Recover a non-solution-aware flow
A non-solution-aware cloud flow can’t have its primary owner transferred in place. Microsoft documents export/import, Save as and Send a copy as replacement routes. A co-owner may also add a supported workflow to a solution before changing its owner.
Choose conversion when retaining the existing identity matters and the workflow supports this approach. Choose a replacement when conversion isn’t suitable, but account for dependencies before switching production activity.
For a copy-based recovery, the intended operating account creates the replacement and selects connections it’s authorised to use. Review its details, triggers, connection references, deployment-specific values and access to the underlying data.
A copied workflow has a new identity. Power Apps, other workflows or external systems may still reference the original, so renaming the replacement won’t reconnect those dependencies.
Test without allowing both versions to process the same live event. Duplicate runs can create repeated notifications, records or approval requests.
Retire the original only after the replacement passes functional testing and dependent applications are updated. Preserve the configuration and relevant run information needed for troubleshooting. A successful manual test isn’t sufficient evidence that a scheduled trigger or app-launched execution works.
Separate Power Apps administration from flow recovery
Power Apps and Power Automate share Power Platform administration tools, but their ownership commands aren’t interchangeable. An app that launches associated automation has two resources to review.
Use app ownership commands for Power Apps
Set-AdminPowerAppOwner changes a Power App’s owner. Its parameters include -AppName for the app ID, -AppOwner for the new owner’s user ID and -EnvironmentName for the environment ID.
The previous owner’s app role becomes Can View, so an owner transfer can leave residual access.
Microsoft’s PowerShell administration documentation provides wider Power Platform context, including PowerShell tools. Use the command for the resource you’re administering, and don’t treat an app ID and a flow ID as interchangeable.
Distinguish permission assignment from ownership
Set-AdminPowerAppRoleAssignment assigns Power Apps permissions. It accepts parameters including -AppName, -EnvironmentName, -RoleName, -PrincipalType and -PrincipalObjectId; CanEdit is an available role.
Granting app edit rights doesn’t give a user responsibility for an associated flow or replace its connections.
Where an app depends on recovered or copied automation, test the action through the app itself. Confirm that intended users can invoke it and that the operation uses the expected permissions. Testing only in the designer can miss a broken app association.
Choose a secure identity and licence
An organisation-owned identity can reduce dependence on a particular employee. It still requires controlled access, suitable authentication, documented custodians and licensing that fits the automation.
A service account is not an MFA exemption
Don’t disable multi-factor authentication (MFA) just to keep automation running. A user-based service account remains a user identity, and authentication requirements can affect its connections.
Keep administrative access separate from routine automation. A process that reads a SharePoint library doesn’t need Global Administrator privileges just because that role makes configuration easier.
Where supported, an application identity such as a Microsoft Entra service principal can use a different authentication model. It has separate responsibility, connector and licensing conditions, and isn’t interchangeable with a licensed user account.
If application credentials are involved, account for Entra client secret expiry. Moving away from an employee’s login doesn’t remove credential maintenance.
Match licensing to the execution model
For automated or scheduled runs using premium connectors, the owner normally needs Power Automate Premium unless the automation has a Process licence. For instant runs using premium connectors, each runner normally needs Premium unless the automation has a Process licence.
Microsoft’s Power Automate licensing FAQ explains that a Process licence gives the flow premium connector access and a dedicated entitlement of 250,000 actions daily per licence.
Assigning one Premium licence to a shared service account doesn’t automatically license unlimited users. Microsoft’s multiplexing rules matter when multiple people benefit from the automation. Choose the licensing route based on the execution and access model.
Make ownership part of the leaver process
Record each business-critical automation’s purpose, environment, primary owner, co-owners, connection identities, licensing route and support contact. Include its dependent applications and the consequences of a missed or duplicated run.
Give critical automations more than 1 authorised maintainer, but distinguish maintenance access from the identity used for execution. Additional co-owners reduce access problems; they don’t remove authentication dependencies.
Before a planned departure, identify personal connections, establish replacements and test the complete business process. Don’t retain a departed employee’s account as the permanent recovery method.
Monitoring also needs an owner. Failure alerts sent only to the person who created the automation may disappear into an unattended mailbox. Direct operational notifications to a maintained destination and document who investigates them.
Our guidance on what managed IT support should include explains why cloud administration and ongoing responsibility need an agreed scope. A support agreement should make clear who has responsibility for business-critical automations, rather than assuming Microsoft 365 support automatically includes every automation.
Frequently Asked Questions
Does changing a flow’s owner update its connections?
No. The owner change doesn’t replace the credentials used by Outlook, SharePoint, Dataverse or another connected service. Replace affected connections with ones the intended operating identity is authorised to use.
Can a Power Automate flow’s primary owner be transferred in place?
Yes, for a solution-aware cloud flow, if the person making the change is an administrator or has the required Dataverse privilege. A non-solution-aware flow can’t have its primary owner transferred in place, so use a supported replacement route or add it to a solution where supported.
What happens when I copy a flow?
The copy has a new ID, and apps, other flows or external systems may still refer to the original. Update those dependencies and test the replacement before retiring the original; don’t let both versions process the same live event.
What licence does a flow using premium connectors need?
For automated or scheduled runs, the owner normally needs Power Automate Premium unless the flow has a Process licence. For instant runs, each runner normally needs Premium unless the flow has a Process licence; a Process licence gives the flow premium connector access and 250,000 actions per day per licence.
Is changing a Power App’s owner enough to transfer its flow?
No. App ownership and flow ownership are separate, and app edit permissions don’t replace a flow’s connections. Test the automation through the app to check that users can invoke it with the expected permissions.
Restore the dependencies as well as ownership
A reliable handover addresses management access, connections, permissions and licensing together. Changing responsibility for the automation completes only part of that work.
Use an in-place transfer where supported. Where a replacement is necessary, preserve dependencies and test the actual business process before retiring the original.
Our Microsoft 365 support services cover account management, permissions, licensing and troubleshooting. Speak to our team about reviewing the Microsoft 365 dependencies behind your business-critical flows and incorporating them into a repeatable leaver process.
