Who Owns This Flow? Managing Power Automate When People Leave

Scenario: The Monthly Customer Export That Nobody Owns

You work in a data team supporting sales operations. A cloud flow runs once a month:

• Pulls customer data from Dataverse
• Writes a summary file to SharePoint
• Sends it to several regional managers

It’s been running fine for months. Then it fails with:

The connection 'shared_office365' is not found or is disabled.

You open the flow and see:

• Owner: a former colleague whose account is now disabled
• Run-only users: a few team members
• Connections: all using the ex-colleague’s personal connections

You need the flow running again today and you don’t want this problem to repeat for other flows.

We’ll use this scenario to anchor the rest of the article.

How Flow Ownership Actually Works

Before fixing anything, it helps to be precise about what “ownership” means in Power Automate.

Cloud flows (most common case)

For standard cloud flows (the ones you build at make.powerautomate.com):

• Every flow has owners and optionally run-only users.
• Owners can edit, delete, share, change connections, and export/import the flow.
• Run-only users can trigger and run the flow (subject to trigger type and permissions) but cannot edit it.
• Each flow runs using connections. Those connections belong to specific users or to service principals (via service accounts / Azure AD app registrations depending on connector support).

Key points:

• If a flow’s owner is removed from Azure AD, the flow object itself usually still exists in the environment, but their connections will be disabled or removed.
• A flow can have multiple owners. Ownership is not limited to one person.
• For solution-aware flows (flows inside Dataverse solutions), ownership and security are influenced by Dataverse roles and solution management, but the basic owner list still applies.

What happens when a user leaves

Typical effects when the owner’s account is disabled or removed:

• Any personal connections they owned become invalid or disabled.
• Flows using those connections start failing with connection-related errors.
• If the user was the only owner, nobody can see the flow from the standard Power Automate portal unless they have environment-level admin rights.

This distinction matters: a flow breaking because of connections is different from a flow being inaccessible because of ownership.

Step 1: Find Out Who Owns What (Before It Breaks)

The cleanest way to handle ownership is to prevent the surprise. You want a repeatable way to:

• List flows in an environment
• See who owns them
• See which connections they use

The most robust way to do this today is via the Power Platform admin tooling.

Use Power Platform Admin Center

If you’re an environment admin or Power Platform admin:

1. Go to admin.powerplatform.microsoft.com.
2. Select the environment where the flows live.
3. Open Resources > Flows.
4. For each flow, you can see:
   • Flow name
   • Type (cloud flow, business process flow, etc.)
   • Owners
   • Status

This gives you visibility, but it’s still manual.

Use PowerShell for inventory

For a repeatable inventory, use the Power Apps Administration PowerShell module. A common pattern:

1. Install and import the module:

Install-Module -Name Microsoft.PowerApps.Administration.PowerShell -Scope CurrentUser
Import-Module Microsoft.PowerApps.Administration.PowerShell

2. Sign in with admin credentials:

Add-PowerAppsAccount

3. Get flows for an environment and export basic ownership info:

$environmentName = "Default-<your-tenant-guid>"  # or another environment ID

$flows = Get-AdminFlow -EnvironmentName $environmentName

$flows | Select-Object \
    DisplayName, \
    EnvironmentName, \
    @{Name='Owners';Expression={$_.Properties.owners | ForEach-Object { $_.displayName } -join '; ' }} \
    | Export-Csv -Path "flows-ownership.csv" -NoTypeInformation

This gives you a CSV with flows and their owners. You can extend it to include creator, last modified date, or other properties.

For our monthly customer export scenario, this is how you’d identify:

• The flow itself
• That the only owner is your ex-colleague

Step 2: Regain Control of Orphaned Flows

When a person leaves and was the only owner, you first need to re-establish ownership.

As an environment admin

If you have environment admin rights:

1. In Power Platform Admin Center, open the environment.
2. Go to Resources > Flows.
3. Find the problematic flow.
4. Open the flow details and use Edit owners (wording can vary slightly) to:
   • Add yourself
   • Add a team owner (security group) or another responsible colleague

Once you’re an owner, you can open the flow in Power Automate and fix connections.

Using PowerShell to add an owner

If you prefer scripting or need to do this at scale, you can use PowerShell. A common pattern:

$environmentName = "Default-<your-tenant-guid>"
$flowName = "<flow-logical-name>"   # not the display name; get this via Get-AdminFlow
$newOwnerEmail = "new.owner@contoso.com"

# Get flow
$flow = Get-AdminFlow -EnvironmentName $environmentName | Where-Object { $_.FlowName -eq $flowName }

# Get user principal object
$user = Get-AdminPowerAppUser -EnvironmentName $environmentName -UserPrincipalName $newOwnerEmail

# Add owner
Set-AdminFlowOwnerRole -EnvironmentName $environmentName -FlowName $flowName -PrincipalObjectId $user.ObjectId -RoleName "CanEdit"

Exact parameters and cmdlet names can vary by module version, but the pattern is:

• Get the flow
• Get the user
• Assign an edit-capable role (owner) to that user for the flow

If you’re not fully sure of the cmdlet syntax in your version, do this via the admin portal instead; the portal path is stable and safer.

For our scenario, once you add yourself as owner, you can open the monthly export flow in Power Automate and see all its broken connections.

Step 3: Fix Connections Without Breaking Ownership Again

The next failure mode is using personal connections that die with the person.

In the monthly export flow, you see connectors like:

• Office 365 Outlook
• SharePoint
• Dataverse

All using the ex-colleague’s account.

Replace connections with a service identity where possible

Where your organisation’s policies allow it, the most resilient pattern is:

• Use a shared service account (or app/service principal depending on the connector) as the identity for key connectors.

Examples:

• For SharePoint: use a service account with appropriate site permissions.
• For Dataverse: use a service account with a suitable security role.
• For Outlook: use a shared mailbox or service account mailbox if supported by your licensing and policies.

Steps inside the flow designer:

1. Open the flow as an owner.
2. In the left panel, open Connections.
3. Create new connections using the service account identity.
4. For each action in the flow, change the connection reference to the new service connection.

This way, disabling a human owner’s account does not kill the connectors.

When you must use personal connections

Some organisations forbid shared accounts or service principals for certain systems. In that case, you can still reduce risk:

• Ensure at least two owners have valid connections for each key connector.
• Use connection references in solution-aware flows, so you can swap connections centrally when ownership changes.

For our monthly export flow, you would:

• Move it into a solution (if not already).
• Use connection references for Dataverse and SharePoint.
• Bind those references to a service account or at least to multiple owners.

Step 4: Design Flows for Team Ownership, Not Individual Ownership

The best technical fix is often to adjust your design so flows are clearly owned by teams, not individuals.

Use security groups or teams as a pattern

Instead of relying on a single named person:

• Make a mail-enabled security group or Microsoft 365 group that represents the owning team (e.g., “Sales Ops Automation”).
• Add several real people to that group.
• Use that group in your governance and documentation as the owner.

While flows still require individual identities for connections, your operational model is now:

• The group is responsible.
• At least two group members are owners in Power Automate.

Standardise environments by team

Another practical pattern:

• Create departmental or solution-specific environments (e.g., SalesOps, FinanceAutomation).
• Assign environment admin roles to group leads.
• Build critical flows in these environments, not in the Default environment.

This makes it easier for the team to:

• Discover flows they own
• Adjust ownership when people move
• Apply environment-level policies (DLP, auditing)

In our scenario, the monthly export flow would live in the SalesOps environment, owned by the Sales Ops Automation group, and built with service account connections.

Step 5: Implement a Joiner/Mover/Leaver Checklist for Flows

Technical patterns only help if HR and IT processes align. You need a simple checklist that runs whenever someone joins, moves, or leaves.

When someone joins a team

Have the team lead or environment admin:

• Add them as owner to key flows they’ll maintain.
• Ensure they have connections set up for the systems those flows use.
• Walk through at least one run history for critical flows so they understand normal behaviour.

When someone moves between teams

Before changing their access:

• Review flows they own using the PowerShell inventory or admin portal.
• For flows that should stay with the old team:
  • Add new owners from that team.
• For flows that move with them:
  • Add owners from the new team.

When someone leaves the organisation

Before disabling their account:

1. Use your flow inventory to list flows they own.
2. For each flow:
   • Add at least one new owner.
   • Replace personal connections with service account connections where allowed.
3. Only then disable the account.

If you can’t change the account timing, environment admins can still recover ownership later, but connection issues may cause downtime.

In our monthly export scenario, a simple leaver checklist would have:

• Identified the ex-colleague’s flows
• Added new owners
• Swapped connections to a service account

The flow would never have broken.

Monitoring: Catch Ownership Issues Before Users Do

Even with good patterns, something will slip. Monitoring helps you react quickly.

Use run history and alerts

For critical flows:

• Review Run history periodically for failures.
• Configure notifications for failed runs (available in flow details).

Common symptoms of ownership/connection problems:

• Repeated failures with messages about:
  • Missing or disabled connections
  • Permission denied on SharePoint, Dataverse, or other systems

When you see these:

• Check whether the failing connection belongs to a leaver.
• If so, apply the ownership and connection fixes described earlier.

Central error reporting flows

Some teams build a meta-flow that:

• Triggers on failed runs across a set of flows (using admin APIs or Power Platform connectors where available).
• Sends a summary email or writes errors to a log list.

This isn’t strictly about ownership, but in practice, many ownership issues surface as connection failures, so central error reporting helps you spot them faster.

One Concrete Takeaway

Pick one environment with business-critical flows and:

1. Generate a flows + owners inventory (via admin portal or PowerShell).
2. Flag flows with a single owner and personal connections.
3. For each flagged flow, add at least one more owner and plan a move to service account or connection references.

Do that once and you’ll prevent most “Who owns this flow?” crises before they ever reach your inbox.