Power Platform Offboarding Checklist

When an employee resigns, most offboarding processes for the laptop, email inbox, and building pass run like clockwork. What almost always slips through the cracks: the flows, Power Apps, and connections that this person built in the Power Platform. A flow that files invoices from an inbox into SharePoint every morning does not initially notice that its owner no longer exists. It simply keeps running until a connection expires or a license is revoked, and then the entire team suddenly faces a stalled process without any explanation.

This checklist is meant as a lead asset: a document you simply work through the next time someone leaves, instead of figuring out from scratch every time where traces of a person are scattered across the Power Platform. It complements our article on Solutions in Power Automate, which explains why only flows within a solution can actually be transferred cleanly. This one focuses on the prevention angle: what you specifically check before, during, and after the last working day so your digital workers keep running, no matter who leaves the company.

Why offboarding in the Power Platform is often forgotten

In most companies, flows and Power Apps aren't recorded in a central inventory. They emerge in a decentralized way, often built by a single specialist who wanted to automate a recurring task. That is exactly what makes them invisible during offboarding: nobody in IT knows a given flow even exists until it suddenly fails after its creator has left.

According to the official documentation on Change cloud flow owner, when a flow is created, the person who creates it automatically becomes its owner. This role determines editing rights, sharing, run history, and in some cases even which license is used. If this person leaves the company without a prior transfer, the flow becomes what Microsoft calls an orphaned flow: an automation without a valid owner, whose connections can fail at any time.

The checklist before the last working day

The most important principle first: everything you can take care of before someone leaves is easier than everything you have to catch up on afterward. As long as the person still has access, you can work together with them instead of reconstructing what even exists as an administrator after the fact.

• Export the flow list: Ask the person to sign in to Power Automate and list all their own flows under "My flows", including flows that appear under "Shared with me".
• Check solution membership: For every flow: only a solution-aware flow can later be transferred cleanly to a new person. For flows that aren't solution-aware, the documentation says the only option is the workaround via export, import, or send a copy, because the owner is part of the flow's identity.
• Add a co-owner: Add a co-owner from the team directly for every critical flow, while the original person is still available and can answer questions.
• Check Power Apps: Likewise, go through their own apps and share co-owner access for every app that other people use in production.
• Document connections: Which connections (SharePoint, Outlook, Dataverse, external APIs) are attached to the person's flows? Connections tied to a personal account will no longer work reliably once the account is deactivated.
• Redirect approval and sharing processes: If the person acts as an approver in an approval flow, this role must be reassigned to someone else before they leave.

The checklist after the last working day

Not every departure allows enough lead time to take care of everything beforehand. In case the person has already left, you need the view from an administrator's perspective.

• Find orphaned flows in the admin center: Open the Power Platform Admin Center, select the affected environment, then Resources > Flows, and specifically search for flows with no entry in the Owner column. This is exactly the approach described in the support article on Manage orphaned flows.
• Assign new co-owners: For every flow found in the admin center, select Share, enter a new owner name, and save. For many affected flows, this can also be done at scale using the PowerShell cmdlets `Get-AdminFlow` and `Set-AdminFlowOwnerRole`, instead of clicking through each flow individually.
• Search for Power Apps belonging to the same person: Under Resources > Power Apps you can filter by the name of the departed person. For every app you find, a single click on Share is enough to give yourself co-owner rights as an administrator.
• Check security group and license: Once the person is deleted from the Microsoft 365 Admin Center, Power Platform automatically sets their status to disabled, which according to the documentation on Delete users from an environment can take between 30 minutes and 6 hours. Don't just wait out this period; actively check whether the status has actually switched over.
• Watch connections for errors: In the affected flows, check the run history for failed runs caused by an invalid connection, and update the credentials to an account that still exists.

What happens if nobody acts

A common misconception is that a flow stops immediately once its owning person leaves. In fact, according to the documentation on team flows, a shared flow simply keeps running for now, as long as it still has an active owner, such as a co-owner. Only once no active owner exists anymore does a transfer become mandatory.

It gets more critical with the license. According to the Power Automate licensing FAQ, a premium flow whose owner no longer has a valid premium license is first downgraded to lower capacity. All owners are notified, and if the situation remains unresolved, Power Automate shuts the flow down completely after 14 days. In practice, these two weeks are the real window of time you have for an orderly transfer before a production automation fails without warning.

Planning ahead: co-owners from the start

The most reliable form of prevention is not an offboarding action at all, but a rule that already applies when a flow is built: every flow and every app used in production gets at least one second person as a co-owner from the very start. That way, when someone actually leaves, all that remains is removing the original owner, instead of scrambling to find a new one under time pressure. Anyone who combines this rule with a lean governance structure, as described in our article on CoE light for 30 employees and additionally limits access to sensitive connector groups via DLP policies for beginners, significantly reduces the risk of an orphaned flow from the outset.

If you don't want to maintain this checklist manually, but want it firmly anchored as a fixed part of your own offboarding process, NordFlux Power Automate consulting provides support in setting up governance and prevention cleanly from the start. This way you keep control over your automations, even as teams change.

Frequently asked questions

What is the difference between an orphaned flow and a flow without a co-owner?

A flow without a co-owner still has a valid, active owner and keeps running normally. Only once that sole owner leaves the organization and nobody takes over the role does the flow count as orphaned, meaning it has no valid owner. That's exactly why a co-owner is the simplest form of prevention: it stops a flow from ever reaching the orphaned state in the first place.

Can I take over someone else's flow as an administrator, even without anyone having shared it with me?

No, not directly. According to the documentation, an administrator must first add themselves as owner or co-owner before making changes to someone else's flow. In the Power Platform Admin Center, this is done via the Share function on the detail page of the relevant flow, where you enter yourself as the new owner name and save the change.

What happens to a solution when its creator leaves the company?

Unlike standalone flows, solution-aware flows can be reassigned to a new person directly in the edit view, without export and import. Once the change is complete, the old and new owner automatically become joint owners, so both retain access to the run history and connection references. You can find more details in the linked article on Solutions in Power Automate.

How long does it take for Power Platform to mark a deleted user as disabled?

According to the official documentation, after deletion in the Microsoft 365 Admin Center it can take between 30 minutes and 6 hours for the status in the relevant Power Platform environments to switch to disabled. If you don't want to accept this waiting period, you can check and speed up the status manually via user diagnostics in the admin center.

Is it enough to delete a person's connections instead of changing the flow owner?

No, that isn't enough and tends to create new problems instead. If you only delete the connection, the flow remains tied to the departed person as owner and runs into a dead end without a working connection. The correct order is the reverse: first transfer the owner to an active person, then update the affected connections with that new person's credentials.