How to inventory an entire Microsoft 365 tenant's Power Platform estate in an afternoon

Ask a Power Platform administrator how many apps their tenant has and you will get a number. Ask again a week later and you will get a different number, from a different export, produced by a different script. The estate is knowable — none of it is hidden — but Microsoft exposes it through four separate admin surfaces, each of which describes a slice and none of which describes the whole.

The four places the estate lives

• Business Application Platform (BAP) lists environments: their type, region, Dataverse status and who created them. It knows nothing about what is inside them.
• PowerApps admin API lists canvas apps per environment, with owner, connections and sharing. It does not know about model-driven apps, which live in Dataverse.
• Flow admin API lists cloud flows per environment with state and trigger — but the V2 listing omits the definition, so connectors and action counts need a second read per flow. Desktop flows are not there at all.
• Dataverse Web API, one endpoint per environment, holds solutions, tables, connection references, model-driven apps, desktop flows and the real owner of every solution-aware flow.

Each API paginates. Each throttles. Each authenticates against a different resource. A complete inventory is therefore not one query; it is several hundred, in the right order, with the identifiers from one used to join the results of another.

What you need to sign in with

Tenant-wide results need a Power Platform Administrator, Dynamics 365 Administrator or Global Administrator account. Anything less returns only the environments the account personally belongs to, silently — the API does not say it is filtering, it simply lists fewer rows. Solutions, tables and connection references additionally need a security role inside each environment's Dataverse database; being a tenant admin does not grant one.

The joins that make it an inventory rather than four lists

1. 1Owners. The apps and flows APIs return an object id, not a name. Resolve them in one batch through Microsoft Graph; an id Graph cannot resolve is almost always a deleted account, and is worth flagging as such rather than left blank.
2. 2Solution membership. Neither the apps nor the flows API says which solution an object belongs to. That lives in Dataverse's solutioncomponents table, keyed by ids that do not quite match the ones the other APIs use — a cloud flow's Flow API name is Dataverse's workflowidunique, not its workflowid.
3. 3Connections to consumers. A canvas app's connection map names the connection; the environment's connection list has its status and owner. Join them, and you can say which apps run on a leaver's personal credentials.
4. 4Desktop flows. Read workflows where category eq 6 and fold them into the flow list, marked as desktop, or your Power Automate count is wrong by however many bots the finance team has built.

Why a stored assessment beats a live query

On a real tenant the full walk takes minutes and several thousand API calls. Doing it on every page load is neither fast nor polite to Microsoft's throttling limits. The pattern that works is one assessment per tenant, stored, refreshed on demand: every page afterwards reads from storage in milliseconds, the numbers on Monday's report are the numbers in Friday's meeting, and a refresh is a deliberate act with a timestamp on it.

What the afternoon looks like

With the joins in place, the order of work is: environments first; then apps, flows, connections and connectors per environment in parallel; then the Dataverse slices where a database exists; then owner resolution in one Graph batch; then solution membership; then the per-flow definition reads. Store the result, build the summary from the stored result, and export from storage. That is an afternoon the first time and a click every time after.