Preventing Key-Person Dependency in Power Automate — Keeping Flows Running After the Person Who Built Them Leaves

“We had an employee who was good with Power Automate, and they automated all sorts of processes around the company. Now they’re leaving next month, and nobody knows what any of the flows actually do.” Consultations of this kind have visibly increased lately. Sometimes they arrive at a later stage still — the person has already left, and “order notification emails stopped arriving last month and there’s nobody who can fix it.”

In an earlier article, “When You Inherit a System With No Source Code and No Documentation — A Practical Playbook for Keeping It Running,” we covered taking over a system whose builder is gone. Power Automate flows are, if anything, more prone to exactly this situation precisely because they can be built without code — and, unlike an executable, they carry no guarantee of simply “continuing to be there.” Flows are tightly bound to their creator’s account and connections, and the way they break changes the moment that account is disabled or deleted. This article confirms, against Microsoft’s official documentation, what actually happens to a flow when its owner disappears, and then lays out what to do before someone leaves, what you can still do afterwards, and the stocktaking and execution-account design that stops key-person dependency arising in the first place — in the order a small or mid-sized company would actually work through it.

1. The Bottom Line First

• The creator becomes the owner of a flow, and the connections used to run it (the authentication to SharePoint, Outlook and so on) are tied to the account of the person who created them. A shared connection can only be used inside that flow, and not even a co-owner can change the credentials of a connection someone else created.¹
• Even after the owner leaves, the flow itself keeps running as long as a co-owner remains. But actions using the leaver’s connections will start failing, so the connections have to be swapped out.¹²
• A flow with no valid owner at all becomes an “orphaned flow.” Administrators can find these on the environment page of the Power Platform admin center (Resources → Flows) and add a new owner via Share. Bulk handling with PowerShell (Get-AdminFlow, Set-AdminFlowOwnerRole) is also possible.²
• Before someone leaves, work in two stages: “add co-owners” and “change the owner.” Reassigning the owner (a handover while they are still employed) is only possible for solution-aware flows; non-solution flows have to be added to a solution or rebuilt via export/import.³⁴
• The problem of notification emails continuing to go out under an individual’s name is avoided by moving sending to a shared mailbox (the “Send an email from a shared mailbox (V2)” action), which is unaffected by anyone leaving. Microsoft’s guidance likewise recommends using a shared sender rather than an individual’s name for routine notifications.⁵⁶
• Service accounts based on shared user accounts are not recommended as a best practice, and service principal ownership is the official recommendation for mission-critical flows. Because there are configuration and licensing hurdles for smaller companies, Section 5 of this article sets out a realistic way to choose between them.⁴⁷⁸
• The first step is not technical — it is taking stock. Start by listing what flows exist across the company using the admin center and Get-AdminFlow, and building a minimal flow register (name, purpose, owner, connections, processes affected).⁹

2. How Flows Become One Person’s Domain

Key-person dependency in Power Automate arises not from malice or negligence, but from an accumulation of good intentions. The typical progression looks like this.

1. Someone knowledgeable on the ground builds a flow to make their own work easier. Something small, on the order of “copy Forms responses into Excel.”
2. It is useful, so colleagues pile in. “Send me that notification for my section too.” “Could it save the purchase orders as well?” Requests accumulate, flows multiply and grow.
3. Before anyone notices, it has embedded itself in core operations. First-line order notifications, invoice storage, routing approvals — processes where “the business stalls if it stops” — end up running on flows in that one person’s individual account.
4. It runs stably without anyone knowing what is inside. There is no reason to touch something that works, so no handover and no documentation ever get written. “We can’t touch it because it’s working” turns straight into “nobody can touch it.”

Up to this point, the picture is the same as a developer leaving and a system remaining with no source and no specification. But Power Automate has two aspects that are more awkward than a legacy system. First, the place flows are built is a person’s “My flows,” where nobody but them can even see that they exist. Unlike a system with an executable sitting on a server, a flow does not even appear in a list until you go and take stock. Second, running a flow depends on its creator’s account and connections. The moment the offboarding process disables or deletes the account, the impact surfaces. The next section confirms exactly how this behaves.

3. What Happens to a Flow When the Account Disappears

The Flow Itself Is Not Deleted, but It Becomes an “Orphaned Flow”

To start with the basics: deleting a leaver’s account from Microsoft Entra ID does not automatically delete the flows they built. Flows and connections are classified as things “an administrator confirms and deletes manually,” so they will not vanish on their own — but run history is automatically deleted when the account is deleted. If you have been relying on past run records as an audit trail, take note.¹⁰

Even when the flow survives, a flow left with no valid owner at all enters a state known as an orphaned flow. Microsoft’s support documentation defines an orphaned flow as “a flow with no valid owner,” and explicitly states that a flow can fail if it uses connections tied to the account of a user who has left the organization.²

Connections Are Tied to That Person’s Account

This is the real pressure point. The connections each action in a flow uses (authentication to SharePoint, Outlook, Teams and so on) run under the credentials of the user who created them. The official FAQ for the case where the creator of a shared flow leaves sets it out as follows.¹

• If a valid owner such as a co-owner remains, the flow itself keeps running
• However, actions using connections in the leaver’s name can fail, so the connection’s credentials need updating (in practice, switching each action’s connection in the flow designer to a connection on a different account)

Furthermore, a shared connection can only be used inside that flow, and even a co-owner cannot change the credentials of a connection created by another owner.¹ In other words, “we’re fine because we added co-owners” is only half right — the handover is only complete once you have done the work of driving the leaver’s connections out of the flow (switching each action to your own connection and saving).

Licensing Fallout — The 14-Day Shutoff

Flows that use premium connectors and the like run on their owner’s license. According to the official licensing FAQ, a premium flow that has lost its licensing backing — because the owner left, for instance — is downgraded to a degraded-performance state, all owners are notified, and it is turned off after 14 days if nothing is done.⁴ It is a timed behaviour: “it somehow got slower,” and two weeks later it stops. Flows using only standard connectors are less exposed to this, but which of your flows use premium features is exactly the kind of information you should establish through stocktaking (the standard/premium boundary is set out in “Power Automate Licensing and the Boundary Between Standard and Premium Connectors”).

Emails Keep Going Out Under That Person’s Name

Something easily overlooked is the “name” on notifications. The “Send an email (V2)” action sends from the mailbox of the connected user, so as long as the flow keeps running, notification emails keep going out under the creator’s personal name. While they are still employed, that is merely a “why do I get an email from that person every morning?” curiosity; after they leave, sending itself fails as the account is disabled. Conversely, if a co-owner just swaps the connection to their own, all the notifications now go out under that person’s name instead.

Microsoft’s guidance recommends avoiding sending routine business notifications under an individual’s name, and using a shared sender instead. With Outlook, the “Send an email from a shared mailbox (V2)” action lets you send from a shared mailbox (for example noreply-flow@example.co.jp), and the send history remains in the shared mailbox’s Sent Items folder (sending requires permission on the mailbox). For Teams notifications, the “post as the Flow bot” family of actions plays the same role. Adding a signature along the lines of “This email is sent automatically by Power Automate; direct queries to X” also means recipients are not left guessing when the responsible person changes.⁵⁶

4. What to Do Before Someone Leaves, and What You Can Still Do After

Before They Leave — Two Weeks Is Enough

Once a departure or transfer is confirmed, work through the following in order.

flowchart TD
    Start[Departure or transfer confirmed] --> Inventory[List the person's My flows<br/>Identify the ones used by the business]
    Inventory --> Coowner[Add the successor and IT as co-owners]
    Coowner --> Solution{Is it a solution-aware<br/>flow?}
    Solution -- Yes --> Owner[Change the owner from the details page]
    Solution -- No --> AddSol[Add it to a solution and change the owner<br/>or rebuild via export/import]
    Owner --> Conn[Switch each action's connection<br/>to a connection on the new account]
    AddSol --> Conn
    Conn --> Mail[Move notification senders to a shared mailbox or similar]
    Mail --> Test[Confirm by a test run that it works<br/>even with the leaver's account disabled]

1. List the person’s flows. Open the My flows screen together with them and sort the entries into “used by the business,” “personal efficiency,” and “leftovers from experiments.” It is efficient to produce the first edition of the flow register from Section 6 right here.
2. Add co-owners. Add the successor and the IT contact (or, failing that, someone with administrator rights) as owners of the flow. Co-owners can view run history, edit, stop, and delete the flow, and add owners.¹ Note that adding co-owners is a minimum stopgap; the official recommendation is to keep day-to-day sharing to run-only wherever possible.⁷
3. Reassign the owner. For a solution-aware flow, you can change the owner to the successor (or a service account) from the flow’s details page. After the change, the original and the new owner both become co-owners, and scheduled and automated flows begin running under the new owner’s license (this can take up to 7 days to take effect; opening and saving the flow applies it immediately).³ For non-solution flows, the owner is part of the flow’s identity, so the owner cannot be changed in place. If Dataverse is available in the environment, add the flow to a solution and then change it; if not, rebuild it under the new owner via export/import or “Save As.”³⁴
4. Swap out the connections. As covered in the previous section, skipping this leaves the handover incomplete. In the flow designer, switch each action’s connection to one on the new account and save. When you remove the leaver from the owners, the credentials on the connections they were using also need updating.¹
5. Test it. If possible, run one full cycle with the leaver’s account disabled (or during a period such as annual leave when they will not be operating anything), and confirm it works under the same conditions that will apply after they have gone.

After They Leave — What an Administrator Can Do

Even if the person has already left and there is no owner, there are still moves available.

• Find the orphaned flows in the admin center. In the Power Platform admin center, select the environment and open Resources → Flows to see the list of flows in that environment. Flows with an empty Owners column are the orphaned ones.²
• Add a new owner via Share. Select the flow in the list, use Share to add the new owner’s account, and save.² Note that if an administrator wants to modify the contents of a flow, adding themselves as owner or co-owner is a prerequisite there too.³
• Handle it in bulk with PowerShell if there are many. With the administration module (Microsoft.PowerApps.Administration.PowerShell), Get-AdminFlow -CreatedBy <the leaver's object ID> enumerates the flows they created, and Set-AdminFlowOwnerRole -RoleName CanEdit grants co-ownership. Check current permissions with Get-AdminFlowOwnerRole.²
• Recreate the connections. After taking over ownership, switch connections in the leaver’s name to ones on the new account. If the leaver’s account has already been deleted, the original connections cannot be recovered, so you will be creating new connections and reassigning them to each action.¹

As a footnote, approval flows have their own distinct way of getting stuck: “pending approval requests still assigned to the person who left.” Reassignment on the approver side and escalation design are covered in Sections 5 and 6 of “Building an Approval Workflow in Power Automate,” so please refer to that.

5. Designing the Execution Account — Individual, Service Account, or Service Principal

To avoid repeating the handover scramble, the fundamental fix is deciding up front “in whose name business flows run.” Here is a comparison of the options.

Here is a practical rule of thumb for choosing.

• Personal efficiency tools can stay on individual accounts. Trying to manage everything strictly just chills the very automation happening on the ground.
• Business flows a department depends on should at minimum have their notification sender moved to a shared mailbox⁵ and have two or more co-owners. If you set up a service account to run them, keep its permissions to the minimum necessary and limit access to the credentials to a handful of people. Microsoft themselves advise using a service principal rather than a service account,⁴ but in smaller-scale operations centred on standard connectors, “a dedicated account plus rigorous password management” is often the realistic answer.
• Flows tied to company-wide core operations (anything directly connected to orders, invoicing, or payments) are worth considering for service principal ownership. Because the owner is no longer a person, they are unaffected by departures, and you avoid the accident of a flow stopping because the owner’s license was removed.⁸ But there are constraints — a service principal cannot be a co-owner (it can only be used as the owner), and premium features require a Process license — so once you are at this point, it is a stage to design with your IT department or an outside specialist involved.⁸

One more thing: even when you do set up a service account, avoid doing all flow creation and minor edits under that name. If the person building it builds under their own account, and only ownership and execution sit with the service account, you retain traceability of “who changed what, and when.”

6. Inventory and Documentation — First, Know What Exists

The starting point for countering key-person dependency is for the organization to understand what flows exist across the company. Just as the first step in taking over a black-boxed system is an inventory of executables and scheduled tasks, flows have their own standard stocktaking playbook.

Getting a List of Flows

• From the admin center: on the Power Platform admin center’s environment page, open Resources → Flows and you get a list of the flows in that environment together with their owners. This is also where you spot orphaned flows.²
• From PowerShell: the administration cmdlet Get-AdminFlow returns every flow in the environments you manage if you are an environment administrator, or every flow in the tenant if you are a global administrator. Get-AdminFlow | Export-Csv -Path '.\FlowExport.csv' gives you the seed of a CSV register straight away, and Get-AdminFlowWithHttpAction narrows it to just the flows using HTTP actions (those most likely to be integrating with something external).⁹ If you are not comfortable with PowerShell, “PowerShell Command Basics — The Operations to Learn First and How to Use Them Safely” is also worth a look.

A Minimal Flow Register

Keeping the register unelaborate is the trick to sustaining it. In a SharePoint list or Excel, one row per flow, with only these columns.

The key one is “whose name each connection is in.” Owners can be seen from the admin screen, but the name on a connection cannot be determined without opening the flow, which makes it the single most valuable piece of information to have written down in the register.

Naming Conventions and the Description Field

Microsoft’s coding guidelines recommend giving flow components descriptive, consistent names, documenting and sharing your naming conventions, and attaching notes to actions that serve the same purpose as code comments.¹¹ In practice, simply standardizing flow names as “[Department] Process name - What it does” (for example “[Sales] Fax orders - Save PDF and notify the owner”) makes a huge difference to how readable the list is. A flow’s details page also has a Description field, and Copilot can generate a draft for it,¹² so putting the same content as the register’s “Purpose” into the flow itself is insurance for the day the register goes stale.

Once you have a register, the next question comes into view: who notices when a flow stops with an error? Failure notification and retry design are covered in detail in “Power Automate Error Handling and Retry Design.”

7. Environments and Solutions — Stepping Beyond “Everything in the Default Environment”

Power Platform has a partitioning concept called the environment, and any flow built without specifying one goes into the default environment. The default environment is accessible to every user in the tenant, and any employee with a Microsoft 365 license can build apps and flows there. As a sandbox for personal productivity that is fine, but Microsoft’s own guidance points out that the default environment tends to accumulate ownerless resources as creators leave, and that flows which become widely shared or business-critical should be moved to a dedicated environment.¹³

A small or mid-sized company does not need to go straight to full environment separation (development, test, production). But two things are worth being conscious of even at small scale.

• Put flows that have entered core operations into a solution. A solution is a container for carrying a flow and its components around together, and a flow inside one (a solution-aware flow) can have its owner changed in place, can hold its connections as easily-swapped “connection references,” and gains version history.³¹⁴ As Section 4 showed, this makes handover on departure incomparably easier. Using solutions requires an environment with Dataverse.¹⁴
• Review your DLP policies at least once. Data loss prevention (DLP) policies, which classify connectors as business or non-business and restrict the combinations, are the safety net against a rogue flow pushing internal data out to an external service.¹⁵ The overall thinking on governance is touched on in Section 9 of “Automating Business Processes with Power Automate.”

Environment separation, ALM (a development → test → production pipeline), and company-wide control via the CoE Starter Kit all lie further down this road, but they are worth considering only once you have flows numbering in the tens. Register and solutions first; environments next.

8. Decision Table — Whose Asset Is This Flow?

Finally, here is how to draw the line on the level at which each individual flow should be managed. Strictly managing every flow is unrealistic, so split them into three tiers by “who is inconvenienced if it stops.”

How to approach a flow that has reached the bottom row is the same as taking over a system with no source and no documentation, mentioned at the top of this article. Rather than rebuilding it straight away, start by observing the trigger, the connections, and the output destinations, and writing “what it does” into the register. Fortunately, unlike an EXE with no source code, a flow shows you everything inside. As long as you can become a co-owner, deciphering the definition itself is not difficult.

There is also the question of “should this processing be kept in Power Automate at all?” Complex flows, which are fertile ground for key-person dependency, can sometimes be more easily handed over if moved to PowerShell scripts, Task Scheduler, or a feature of the business system itself, since those can be put under Git management and code review. That choice is set out in “Choosing Between Power Automate and PowerShell + Task Scheduler.”

9. Summary

• A flow is tied to its creator’s account and connections. When an account disappears on departure, the flow itself remains, but the run history is deleted automatically, actions using connections in the leaver’s name fail, and premium flows are turned off after a 14-day grace period.¹⁰²⁴
• Before someone leaves, two weeks is enough for a handover in this order: add co-owners → change the owner (if solution-aware) → swap out the connections → move the sender name to a shared mailbox.³¹
• Even after they have gone, you can find orphaned flows via the admin center’s Resources → Flows or PowerShell (Get-AdminFlow/Set-AdminFlowOwnerRole) and reassign ownership. Recreating the connections, however, is unavoidable.²
• The fundamental fix is stocktaking with a flow register, naming conventions and description fields, moving notification identities to shared senders, and designing the execution identity of important flows away from individuals (service accounts with caution; service principals for core operations).¹¹⁶⁷
• Decide for each flow whether it is a “personal tool,” a “team asset,” or “company infrastructure,” and match the weight of management to that. That, in our view, is the realistic line that prevents key-person dependency without chilling automation on the ground.

Even if nobody is scheduled to transfer or leave, we recommend running through everything up to Section 4 of this article once, as a fire drill. If you get stuck on taking stock of your flows, designing a handover, or deciding whether something belongs in Power Automate at all, do get in touch.

Related Articles

• Automating Business Processes with Power Automate — Cloud Flows, Desktop Flows, and Robust Error Handling
• Building an Approval Workflow in Power Automate — Digitizing Paper and Email-Based Approval Requests
• When You Inherit a System With No Source Code and No Documentation — A Practical Playbook for Keeping It Running
• Power Automate Error Handling and Retry Design
• Power Automate Licensing and the Boundary Between Standard and Premium Connectors

Related Consulting Areas

KomuraSoft LLC handles everything from investigating the handover of automation and business systems that nobody can touch after a staff member’s departure or transfer, through Power Automate operational design reviews, to turning processing that has outgrown a flow into a proper system.

• Technical Consulting & Design Review
• Windows App Development
• Contact

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Frequently Asked Questions

Common questions about the topic of this article.

What happens to a Power Automate flow when the person who built it leaves the company?

The flow itself is not deleted automatically when the leaver's account is deleted, and it keeps running as long as a co-owner remains. However, the connections inside the flow (the authentication to SharePoint, Outlook and so on) are tied to the account of the person who created them, so actions using the leaver's connections will start failing once the account is disabled or deleted. In addition, a flow left with no valid owner becomes an "orphaned flow," and a flow using premium features whose owner's license has been lost gets its performance degraded and is disabled after 14 days if nothing is done. Adding co-owners and swapping out connections before the person leaves is what matters.

Can an administrator take over flows built by someone who has left?

Yes. In the Power Platform admin center, select the environment and open Resources → Flows, and you can see orphaned flows with no owner and add a new owner via Share. If there are a lot of flows, you can list them with Get-AdminFlow from the administration PowerShell module and add co-owners in bulk with Set-AdminFlowOwnerRole. Note, though, that taking over ownership does not make the leaver's connections work again — you still need a separate pass to switch each action's connection over to one on the new account.

Is adding co-owners enough as a departure countermeasure?

It is not enough. A co-owner can edit, stop, and add owners to a flow, but cannot change the credentials of a connection someone else created, and a shared connection can only be used inside that one flow. Actions using the leaver's connections only keep running once a co-owner has swapped in their own connection. The problem of notification emails continuing to go out under the leaver's name also remains, so this needs to be paired with design decisions: sending from a shared mailbox, and moving business-critical flows onto a dedicated execution account or service principal ownership.

Should we create a shared service account to run flows?

It is an option, but Microsoft does not recommend service accounts based on shared user accounts as a best practice. Because the password is shared among several people, it is hard to trace who changed what, and managing the password is itself a risk. If you do use one, keep its permissions to the minimum necessary and limit who can access it. For mission-critical flows, service principal ownership — which does not depend on a person's account — is the officially recommended approach, but note that configuring it requires IT knowledge, and a Process license is needed if the flow uses premium features.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.