GOVERNANCE · April 25, 2026 · 12 min read
What is actually running in your Power Platform tenant? Find out before Copilot, before migration, before the audit.
Walk into any Microsoft 365 admin meeting and ask the room a few simple questions. How many Power Automate flows are running in your tenant right now? How many of those flows are owned by people who left the company two years ago? Which connectors are blocked by your DLP policy and still referenced by live flows? How many premium-licensed connectors are in use that nobody is tracking? Which environments have no governance policy attached at all?
The answers usually arrive in one of three forms. The confident admin guesses, which is worse than not answering. The careful admin says “let me get back to you,” which is not an answer either — it is a promise that will quietly expire. And the honest admin says “I do not know, and I am not sure how to find out.” That last answer is the most accurate one in almost every tenant.
This is not a knowledge problem. The data exists. Microsoft publishes APIs that return all of it. The problem is that the data lives behind three different API surfaces with three different authentication patterns, the official admin center makes you click through one environment at a time, and there is no built-in way to cross-reference the pieces. So the audit does not happen, and the surface area grows in the dark.
Why this matters now, not next quarter
The Power Platform footprint inside a typical Microsoft 365 tenant has been quietly compounding for years. Citizen developers built flows. Department leads built canvas apps. Trial environments spawned themselves the first time anyone with a Power Apps license opened make.powerapps.com. None of this was a problem when nobody was looking at it. Three forces in 2026 mean somebody is about to look.
Microsoft 365 Copilot rollouts. Copilot itself does not use Power Platform. But once Copilot is in production and end users start asking it to do real work, the surface where prompt outputs reach external systems is exactly the citizen-developed flow and app layer. A Copilot output that triggers a flow that hits an unsanctioned external connector is the textbook governance gap. DLP rails that were optional last year are load-bearing this year, and DLP rails are useless if you do not know which connectors they need to govern.
Cross-tenant migrations and M&A activity. When two tenants merge, the Power Platform footprint of both has to be reconciled. Flows that point at SharePoint sites need to follow those sites to their new home. Apps with hard-coded environment IDs need to be rewired. Dataverse solutions need to be inventoried before anyone can decide which ones are coming along and which ones are being left behind. None of this is hard, but all of it is impossible without a complete starting picture.
Regulatory and audit pressure. SOC 2, ISO 27001, and increasingly the privacy frameworks ask a question that sounds simple: what external systems does your tenant integrate with? In a tenant with two hundred flows and fifty apps, the honest answer is a list of every connector referenced anywhere, with usage counts and DLP classification. Auditors are starting to ask for that list as a deliverable, not a verbal summary.
What the Power Platform Inventory does
One read-only scan, run with a single Azure AD service principal, produces a tenant-wide picture across six integrated views. Nothing is modified. Nothing is deleted. The scan finishes in a few minutes on a typical tenant and the results persist so monthly re-runs show drift instead of starting over.
| Data slice | What you see |
|---|---|
| Environments | Every environment Microsoft created or your team created — Default, Production, Sandbox, Trial, Developer — with region, type, and Dataverse status. Most tenants have more environments than admins think. Trial environments auto-create the first time anyone with a Power Apps license opens make.powerapps.com. |
| Power Automate flows | Per environment: name, owner, state (Started, Stopped, Suspended), connectors used, premium flag, last modified date. The full Power Automate inventory in one screen. |
| Power Apps | Canvas and model-driven, both. Owner, connectors used, premium flag. The full Power Apps inventory cross-environment. |
| Dataverse solutions | Name, publisher, version, managed or unmanaged. The unmanaged solutions in the Default environment are usually the ones worth looking at first. |
| DLP policies | Every Business, Non-Business, and Blocked classification on every connector, at tenant and environment scope. |
| Connector usage matrix | The most valuable view. Every connector referenced anywhere in the tenant, with flow counts, app counts, premium flag, and DLP cross-reference (which policies classify it where). |
The matrix is what answers the question every architect actually wants answered: what would break if I touched this? Every flow has a connector dependency. Every app has a connector dependency. The matrix collapses both views into a single table where each row is a connector and each row tells you the full blast radius. Sort it by usage count and you have your prioritization for the next governance project. Filter it to premium-only and you have your licensing audit. Filter it to “referenced and blocked” and you have your list of silently broken automations.
The findings most tenants do not expect
The patterns repeat across tenants. The numbers vary. The categories do not.
Orphan flows. Flows whose owner email no longer resolves in the directory — almost always because the creator left the company and the flow was never transferred. Mid-size tenants typically have dozens of these. Large tenants have hundreds. Orphan flows are operationally radioactive: they cannot be edited or disabled by anyone except a Global Admin, and sometimes not even then without a support ticket. They keep running, they keep failing, and nobody owns the failure.
Stale flows. No modifications in 90 or more days. Not inherently broken — some stable automations should not need touching — but worth a per-flow conversation. Is this still needed? Is the business process it supports still happening? Does anyone remember what it does? In a tenant with 400 flows, the stale set is usually north of 100.
Connectors blocked by DLP and still in use. This is the silent killer. A flow or app references a connector that the active DLP policy has placed in the Blocked bucket. The connector cannot run, but the flow is not labeled broken anywhere visible. Each invocation fails, the failure is logged in flow run history that nobody monitors, and the business process the flow supports just stops working. Users complain to the help desk about the symptom (“the approval email never arrives”) without anyone connecting it to a DLP change made six months ago.
Premium connector sprawl. Per-User and Per-App Power Apps licenses cost real money. Tenants routinely have 30 or more apps using premium connectors with no central record of which apps need which licenses, which means either users are unlicensed and the apps are silently degrading, or the company is overlicensed and paying for headroom nobody is using. Both ways, money is on the floor.
Default environment as production. Every tenant has a Default environment that Microsoft created on day one. It is not supposed to host production solutions. It frequently does, because it is the path of least resistance and because most makers do not know they should pick somewhere else. A Default environment with unmanaged solutions, a Dataverse database, and dozens of business-critical flows is a governance smell that becomes a real problem the moment anyone tries to apply a different policy at the environment level.
No DLP policies at all. The most common finding in small and mid-market tenants. Zero governance rails. Every connector reachable from every flow. This is the single most important thing to fix before turning Copilot on, and it is invisible until somebody runs an inventory and notices.
What this saves
Consider the manual alternative. An M365 governance consultant without an inventory tool does this:
- Open the Power Platform Admin Center, click into each environment one at a time.
- Open the Flows tab, scroll, filter, page through hundreds of flows. Pagination is slow, the UI is not built for bulk reading.
- Open each flow’s details panel to see its connectors. Note them in a spreadsheet.
- Repeat the entire process for the Apps tab.
- Open each Dataverse-enabled environment and query Solutions through a separate UI.
- Open the Policies blade and manually note which connectors are in which bucket for each policy.
- Build a master spreadsheet by hand. Cross-reference flows against connectors against DLP policies. Notice almost nothing useful, because the data is in five different places and the eye glazes over by environment three.
Realistic time on a mid-size tenant with 5 to 10 environments, 200 or so flows, and 50 or so apps: 8 to 16 hours, usually spread across multiple sessions because the consultant gets tired and the admin center pagination is slow enough to break flow state. The output is a spreadsheet that goes stale the moment the next maker creates a new flow.
The MigrationFox Power Platform Inventory: 5 minutes. One scan. Six integrated views. Connector matrix built automatically. CSV export ready for handover or audit attachment. Re-runnable monthly so the picture stays current instead of going stale.
For a consulting firm, that is roughly $1,200 of billable time recovered per engagement, redirected from data gathering to actual recommendations. For an internal IT team, it is a multi-day project that becomes a coffee break. For a managed service provider running quarterly governance reviews across a portfolio, it is the difference between offering the service profitably and not offering it at all.
What you do with the answers
The inventory is the start, not the finish. Once the picture exists, the action items write themselves.
For the orphan flows: bulk-reassign owners through the admin center, or stop and archive the ones nobody can identify a current owner for. The inventory gives you the list; the remediation is fast once the list exists.
For the stale flows: a one-line email to the owner of each (“is this still needed?”) cleans up most of the set in a week. The flows where the owner says “what flow?” are the ones to disable.
For the blocked-but-referenced connectors: two paths. Either the connector should be unblocked because the business process is legitimate, in which case the DLP policy needs adjusting. Or the flow should be archived because the connector was blocked deliberately and the flow is dead. Either way, the silent failure ends.
For premium connector sprawl: compare the matrix to your license inventory. Usage counts tell you which apps need Per-User licensing for which user populations and which apps are candidates for Per-App licensing instead. The math becomes possible.
For the Default environment: set a policy that all new solutions go into a managed environment, then plan a migration of the high-value items out of Default into properly governed homes. The inventory tells you what is in Default that needs to move.
For the no-DLP-at-all finding: start with a tenant-default policy that puts every connector in Non-Business and a small set of high-risk connectors (HTTP, SQL Server, Azure Blob, custom connectors) in Blocked. The matrix shows you which connectors actually need policy attention because they are in active use. Build forward from there instead of guessing.
Pricing and how to start
Power Platform Inventory is part of the MigrationFox Governance Assessment suite. It runs standalone for CA$399 one-time per tenant, with 90-day access to the results dashboard, CSV export, and re-run capability. Or include it in the Copilot Readiness bundle at CA$1,599 — six assessment modules covering Copilot Readiness, M365 Complete, Power Platform, SharePoint and OneDrive oversharing, Teams governance, and M365 Security, with a commercial redistribution license included for consultants who want to sell the assessment under their own brand.
The free tier includes one inventory scan per tenant per month. That is enough to see the output, validate the findings against your own knowledge, and decide whether the assessment belongs in your governance workflow before anything is purchased. No credit card required to sign up.
To run the first scan you need three things:
- An Azure AD service principal (app registration) with the Power Platform Administrator directory role assigned.
- A one-time PowerShell call to register the service principal as a management app:
New-PowerAppManagementApp -ApplicationId <clientId>. This is the step the official documentation buries and that most teams miss on the first attempt. - For full Dataverse coverage, an Application User with System Administrator role on each environment whose solutions you want enumerated.
The tool degrades gracefully. If a permission is missing, the affected category comes back empty and the dashboard shows a checklist of which prerequisite is missing and which command or admin center screen fixes it. Run the scan, see the gaps, grant the missing access, re-run. The full setup walkthrough lives at /power-platform-inventory.html.
The visibility is the point
Audits are not interesting. Nobody wakes up wanting to inventory their tenant. The point of the inventory is not the inventory itself; it is that the absence of one is the silent reason most governance projects stall, most Copilot rollouts ship with gaps, and most cross-tenant migrations break in places that were technically discoverable in advance and were not discovered.
A read-only scan does not change anything in your tenant. It tells you what is there. From the data you can decide what to do — disable the orphan flows, classify the unclassified connectors, archive the stale environments, license the premium apps correctly, fix the DLP gaps before Copilot finds them. The decision-making becomes possible because the visibility exists. Without the visibility, the decisions get deferred indefinitely and the surface area keeps growing.
Run the scan. The data will surprise you. The remediation will be more obvious than you expected. And the next time somebody asks how many flows are running in your tenant, the answer will be a number instead of a pause.