Can you make one person co-owner of every app in the tenant?
A Power Platform administrator can list every app in the tenant and open none of them. Here is why that gap blocks migrations and leaver clean-ups, and how to close it in bulk rather than one app at a time.
Being a Power Platform Administrator gives you a complete list of every app in the tenant. It does not give you the ability to open a single one of them.
That surprises people the first time, and then it stops being a curiosity and becomes a blocker — usually on the morning somebody needs to move forty apps into solutions, or the week after a maker leaves and four of their apps turn out to run a finance process.
Listing and opening are different permissions
The administrative surfaces are deliberately split. An admin role lets you enumerate and govern: see every app, see its owner, see who it is shared with, delete it, change its owner. Opening an app in the maker portal and editing it is a maker action, and it requires that the app be shared with you like it would be with anybody else.
This is a sensible design. “I can see the estate” and “I can read everyone’s work” are not the same claim, and plenty of organisations want the first without automatically granting the second.
It is also, on the day of a migration, completely in the way.
Why it blocks a migration specifically
Because you cannot add an app to a solution you cannot open.
Most of what a maker builds does not start life in a solution — it is created straight into the environment, very often the default one. Before any of it can be moved properly it has to be added to a solution, because the solution is the unit of transport. That is a maker action on each app, performed by somebody who can open it.
So the real sequence on a migration is:
- Work out which apps are moving.
- Discover that nine of their owners have left and the rest are busy.
- Get yourself co-ownership of all of them.
- Then start the actual work.
Step three is where a week goes, because the obvious route is one app at a time.
The PowerShell route, and why it is not quite enough
Microsoft does expose this. The Power Apps administration module for PowerShell has cmdlets for setting an app’s owner and for granting a role on an app or a flow, and an administrator can run them against objects they do not own. If you know the environment name and the app id, you can grant yourself co-ownership from a terminal.
Two things make that less of an answer than it looks.
You need the ids. Not display names — ids, per app, per environment. Which means you are back to building the list first, and display names are not safe to match on: two environments routinely hold apps called the same thing, and a script that matches on the name quietly acts on the wrong one.
It is a loop somebody has to write. Not hard, but it is now a script that exists, that somebody ran against production, and that nobody reviewed. For a one-off that is fine. For something you will do again at the next migration it is an unowned artefact.
Co-ownership is a disclosure, so treat it like one
This is worth saying plainly, because the bulk version makes it easy to do without thinking: granting yourself co-ownership of somebody’s app gives you their work. On an app that handles HR cases or payroll data, that is a decision, not a chore.
The questions worth answering before the loop runs:
- Which apps, specifically — not “all apps”, but the named set that is actually moving.
- Who is being granted the access, and for how long.
- Who was told. An app owner finding out from the maker portal that they have a new co-owner is a bad way for them to find out.
- What removes it afterwards.
None of that is onerous. It is one paragraph in the migration plan, and it turns an action that looks like overreach into one that was agreed.
Doing it from the list you already built
The reason this is a Power Insights feature rather than a script is that the list is already there. A migration project already knows exactly which apps are in scope, in which environments, by id. Taking co-ownership of all of them is one labelled action against that set — twenty-four apps in one go rather than twenty-four trips to PowerShell — and the same menu exports a users-per-app CSV: the owner plus everyone it is shared with, by email address.
The export matters as much as the grant. Before you take ownership of anything it tells you who currently has it, which is both the list of people to notify and the evidence of what access existed beforehand.
The leaver case is the same problem, smaller
Everything above applies when somebody leaves, with one difference: there is no owner to ask. An app whose owner no longer resolves in the directory has nobody who can add it to a solution, nobody who can fix it, and nobody who will notice when it breaks.
Finding those is the first half, and it is a straightforward query against the inventory once the inventory exists. Reassigning them is the second, and it is the same bulk action — which is why it is worth having the list standing rather than building it in a hurry on the Monday after somebody’s last day.
Power Insights governance flags objects whose owner no longer resolves and exports who has access to what; migration planning does the bulk co-ownership against a named set of apps.
