A read-only governance model: why your Power Platform assessment tool should not need write access to your tenant
The tool that tells you what is in your tenant should not be able to change it. This is the case for a read-only governance model — the permissions it needs, the ones it must not have, and how to tell the difference on a consent screen.
LogiSam··6 min read
Governance tooling is trusted with two things: a complete view of the estate, and the credentials to obtain it. The first is the point. The second is the risk. A tool that can read everything and also write anything is an administrator account with a nicer interface, and it should be reviewed like one.
What read-only means, precisely
- Every call to Microsoft is a
GET, with three deliberate exceptions described below. - No app, flow, connection, solution, table or row is created, modified or deleted by an assessment.
- What is stored is metadata — names, ids, owners, definitions, sharing — never the contents of business tables.
- Access is delegated: the tool acts as the signed-in administrator, sees exactly what they can see, and loses access when they do.
Delegated, not application
An *application* permission lets a service act on the tenant without a user present, under its own identity, typically with tenant-wide scope. A *delegated* permission lets it act as a specific signed-in person, bounded by that person's roles. For governance tooling, delegated is the right model: the estate the tool reports is the estate the administrator is entitled to see, the audit trail names a person, and revoking one account revokes the tool.
The consent screen, read carefully
A read-only assessment needs roughly: PowerApps Service *User*, Flow Service *Flows.Read.All*, Dataverse *user_impersonation* (which sounds worse than it is — it is the only Dataverse delegated scope, and it is bounded by your security roles), and Microsoft Graph *User.ReadBasic.All* to turn owner ids into names. What it does not need: *Flows.Manage.All*, *Directory.ReadWrite.All*, any application permission, or a mailbox scope.
The exceptions, and why they are labelled
Some governance jobs are writes. Granting yourself co-owner of a flow before a migration. Adding flows to a solution. Creating the solution. A tool that refuses to do these is less useful; a tool that does them silently is dangerous. The middle path is that each write is a separate, named action, started by a person, run under that person's permissions, with a preview of exactly what will change and an audit entry when it does.
Questions to ask any vendor
- 1Which permissions do you request, and which of them allow writes?
- 2Do you act as me, or as your own application identity?
- 3What do you store, where, and for how long?
- 4Which actions in your product change my tenant, and how would I know one had run?
- 5What happens to my data if I revoke your access today?
Keep reading
The Power Platform Center of Excellence Starter Kit and Power Insights: what each does best
Microsoft's CoE Starter Kit is the reference toolkit for a Power Platform Center of Excellence, and many tenants run it well. Power Insights covers some of the same ground and none of some of it. This is a plain account of which does what, written for the administrator who has to decide whether they need one, the other, or both.
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.
Power Apps migration planning: the dependency checklist nobody gives you
Moving a Power App between environments or tenants is rarely hard because of the app. It is hard because of the eleven things the app quietly depends on, none of which appear in the export dialog. This is the list, in the order they bite.