Sharing a Power App or flow with yourself as an admin — legitimately
Being a Power Platform Administrator lets you list every flow in the tenant. It does not let you open one. Before a migration or an incident, that gap has to be closed — here is how it is done through the admin surfaces, and how to leave an audit trail while doing it.
LogiSam··6 min read
The admin APIs are deliberately split from the maker APIs. Administration lets you see, disable, delete and reassign; making lets you open, edit and run. An administrator who needs to look inside a flow — to read its actions before a migration, to find the SQL it runs, to repair it after its owner left — needs a maker role on that flow, and being an administrator does not confer one.
Cloud flows
The PowerShell cmdlet Set-AdminFlowOwnerRole grants a principal a role on a flow. Behind it is the Flow admin API's modifyPermissions operation, which takes the principal's object id and a role name: CanEdit makes them a co-owner, CanView a run-only user. It works on any flow in the environment, shared or not, and the grant appears in the flow's *Owners* list exactly as if the owner had added you.
Canvas apps
The PowerApps admin API has the equivalent modifyPermissions on an app. Grant CanEdit for co-owner or CanView for user. The request also carries a flag that decides whether the person is emailed about the share; for an administrator granting themselves access, suppress it.
Desktop flows
Desktop flows are Dataverse rows, so sharing one is a Dataverse GrantAccess on the workflow record, with the access mask for read and write. The principal is your systemuser row in that environment — look it up by your Entra object id — not your Entra id directly.
When it is appropriate
- Before a migration, so the plan can read definitions and packages rather than guess.
- When an owner has left and the flow has to be repaired or reassigned.
- During an incident, to read what a failing flow actually does.
And when it is not: routinely, to everything, because it is possible. A co-owner grant is a change to the tenant. Grant view access where reading is enough, grant it to the account doing the work rather than a shared admin account, and write every grant somewhere that survives the session.
Leaving a trail
Each grant should record who did it, to which object, in which environment, with which role, and when. Microsoft's own audit log captures the permission change; your inventory should too, in words a governance board reads — "granted herself co-owner of *Invoice Approval* in *Finance – Prod* for migration project *Q4 move*" — because that is the sentence that will be asked for.
Keep reading
"Who owns this flow?" — resolving SYSTEM, team and departed owners in Power Automate
Half the flows in a mature tenant show no owner at all in the Flow API. They are not orphans — they belong to SYSTEM, to a team, or to a person who has left — and each of those needs a different action. Here is where the real owner lives and how to read it.
Desktop flows are part of your estate too — inventorying Power Automate for desktop from Dataverse
The finance team has eighty desktop flows running month-end. None of them are in your flow count, because the API you are counting with cannot see them. They are in Dataverse, and here is how to bring them into the inventory before they surprise a migration.
How to inventory an entire Microsoft 365 tenant's Power Platform estate in an afternoon
Every environment, every Power App, every Power Automate flow, every connection — the estate is all there, spread across four admin APIs that each refuse to describe the whole. Here is how to bring it into one list, and what to do about the parts Microsoft will not tell you.