GOVERNANCE · April 22, 2026 · 9 min read

Power Platform Inventory and the New Restructuring Planner

Two features shipped this week that sit at opposite ends of the migration lifecycle. One answers a question most tenants cannot answer at all: what is actually running in our Power Platform environments right now? The other answers a question every architect has asked on a restructuring call: can I just rearrange this in the tool instead of writing another spec document?

Both grew out of the same observation. The pre-migration audit and the site-split planning session are the two places where consultants burn the most hours for the least visible output, because there are no good tools for either job and the manual work does not scale.

The Audit Problem Nobody Wants to Do

Ask an M365 admin how many Power Automate flows exist in their tenant and you will usually get a pause, then a guess. Ask how many of those flows are owned by people who left the organization and you will get a longer pause. Ask which connectors are blocked by DLP policy and still referenced by live flows and the conversation ends.

The reason is structural. Power Platform inventory is spread across three API surfaces: the Business Application Platform (BAP) API for environments and governance, Dataverse Web API for solutions, and the per-environment Flow and PowerApps admin APIs for actual artifacts. Each needs its own authentication pattern. Each returns paginated JSON in a different shape. And the permission model requires a service principal that has been explicitly registered as a management app via PowerShell — something most admins have never done because the official docs bury it three clicks deep.

So the audit does not happen. A tenant goes to cutover with an unknown number of flows silently failing because their SharePoint connector points at a site that just got moved. A tenant rolls out Copilot with no DLP policies configured at all, which means every premium connector is reachable from every flow and the governance rails were never installed. A consultant gets handed a tenant and has to discover that half the canvas apps have no owner because the creators left eighteen months ago and nobody noticed.

What the Power Platform Inventory Surfaces

The new inventory tool connects once with a Power Platform Administrator service principal and produces a tenant-wide picture across five categories. Everything is read-only. Nothing is modified. The scan runs in a few minutes on a typical tenant and results persist so you can re-run monthly to see drift.

Environments

Every Power Platform environment the tenant owns — Default, Production, Sandbox, Trial, Developer — with its Azure region, environment type, creator email, and Dataverse provisioning status. This is the map. Most tenants have more environments than their admins think, because Trial environments are auto-created by Microsoft whenever a user with a Power Apps license opens Make.PowerApps.com for the first time. You will often find a handful of orphan Trial environments in tenants where nobody knows why they exist.

Dataverse solutions per environment

Name, publisher, version, managed or unmanaged. Managed solutions are usually installed by Microsoft or by ISV packages and are safe to ignore. Unmanaged solutions are where the tenant’s own customizations live — and unmanaged solutions in the Default environment are a specific red flag, because the Default environment is not supposed to hold production solutions but frequently does.

Power Automate flows per environment

Owner, state (Started / Stopped / Suspended), connectors used, premium flag, last modified date. This is the biggest surface in most tenants and the one with the most rot. Every flow gets classified along three axes: is it running, does it require premium licensing, and when did anyone last touch it. A tenant with 400 flows, 30% of them stopped, and 80 of them untouched for a year is a tenant with a governance project waiting to happen.

Power Apps per environment

Canvas apps and model-driven apps both. Owner, connectors used, premium flag. Canvas apps accumulate the way OneDrive accounts do — someone builds a timesheet app, ships it to their team, moves on, and nobody ever touches it again. Five years later it is still running on a retired executive’s SharePoint list.

DLP policies and the connector usage matrix

Every tenant-level and environment-level Data Loss Prevention policy, with its Business / Non-Business / Blocked connector buckets. And, crucially, a cross-referenced matrix: for every connector that appears anywhere in the tenant, how many flows reference it, how many apps reference it, whether any active DLP policy blocks it, and whether it requires a premium license.

The matrix is where most of the interesting findings actually live. It is one thing to know a tenant has DLP policies. It is another thing to know that 12 flows reference the HTTP connector and the HTTP connector is in the Blocked bucket of the tenant-default policy — meaning those 12 flows are already silently broken and nobody has noticed because nobody is monitoring flow run history.

The Risk Highlights

The inventory also produces a set of named risk findings that translate the raw data into something you can act on:

• No DLP policies configured. The tenant has zero governance rails. Every connector is reachable from every flow. This is the most common finding in small and mid-market tenants and the one Copilot rollouts need to fix first.
• Connectors blocked by DLP but still referenced. Flows or apps that already cannot run because the connector they use is in a Blocked bucket. Find them, confirm they are dead, archive them, and clean up.
• Orphan flows. No owner email resolvable in the directory — typically the creator left the tenant and the flow was never transferred. Orphan flows are landmines because they usually cannot be edited or disabled by anyone except a Global Admin, and sometimes not even then.
• Stale flows. More than 90 days since last modified. Not inherently wrong, but worth a conversation: is this flow still needed, is the business process it supports still happening, does anyone know what it does.
• Orphan apps. Canvas or model-driven apps with no owner. Same problem, same remediation.

Why This Matters Before Migration or Copilot

For pre-migration audit, the inventory is the piece that answers “what will break when we move this tenant?” Every flow has a connector profile. Every canvas app has a connector profile. When you move a SharePoint site, switch an Exchange domain, or restructure a Dataverse environment, the list of things that could silently break is exactly the list of artifacts referencing those targets. You cannot triage what you have not inventoried.

For M365 Copilot readiness, the inventory is about governance rails. Copilot on its own does not care about Power Platform. But Copilot plus citizen-developer flows means end users can wire Copilot outputs into business processes that hit external systems — and without DLP policy buckets configured correctly, that surface is unbounded. A Copilot Readiness assessment that ignores Power Platform is missing a material part of the risk picture. The new inventory fills that gap.

For compliance, the inventory is a connector dependency map. “What external systems does this tenant actually integrate with” is a question every SOC 2 or ISO 27001 auditor asks, and the honest answer is usually some version of “let me get back to you.” The matrix answers it directly: here is every connector, here is how heavily it is used, here is whether DLP permits it.

Prerequisites

The inventory uses the Business Application Platform API, which means it needs a service principal that has been explicitly registered with Power Platform. The one-time setup is:

• A service principal (app registration) in the tenant’s Azure AD.
• The Power Platform Administrator directory role assigned to that service principal.
• A one-time PowerShell call: New-PowerAppManagementApp -ApplicationId <clientId>. This is what tells Power Platform that the service principal is a management app rather than a regular tenant app, and it is the step most teams miss.
• For flow and app enumeration per environment: Environment Admin role on each environment. Without this the environment still appears in the list but flows and apps inside it come back empty.
• For solution enumeration: a Dataverse app user on each environment that has Dataverse provisioned. Solutions live behind the Dataverse Web API, which is a separate authorization layer.

The tool degrades gracefully. If any of these prerequisites is missing, the affected category comes back empty and the findings page shows a checklist of what is missing and which PowerShell command or admin center screen fixes it. You do not need to get everything right on the first try. Run it, see the gaps, grant the missing permissions, re-run.

Full setup walkthrough lives at /docs/requirements/power-platform-inventory.

And the Restructuring Wizard Got a Major Upgrade

The other feature that shipped this week is a different kind of tool for a different kind of problem. If the Power Platform Inventory is about making the invisible visible, the Restructuring Wizard upgrade is about making the plan malleable.

The old Restructuring Wizard generated a read-only report. You pointed it at a SharePoint site, it analyzed the permission groups and library structure, proposed a set of target sites, and gave you a single Execute button. That worked for the simple case — “split this mega-site into three sites along its natural permission boundaries” — but every real engagement has a moment where the client looks at the proposal and says “we like the idea but not quite that split.” At which point the architect went back to a spreadsheet, rebuilt the plan by hand, and came back next week.

That loop is now gone. The wizard is an interactive planner.

The Architect’s Planner

The new wizard keeps the automatic analysis — permission groups are still detected, a default target proposal is still generated — but every element of the proposal is editable. Specifically:

• Rename target sites inline. The auto-generated site names are rarely the names the client wants. Click and edit.
• Rename target libraries inline. Source library name is shown alongside the target for reference. “HR Benefits” can become “MX HR Benefits” without leaving the screen.
• Move libraries between sites. Each library has a Move-to dropdown listing every other target site. If the auto-proposal put a library under the wrong collection, reassign it in one click.
• Add empty sites from scratch. A plus-button creates a new target site collection with no libraries. Useful when the architect wants a site that does not map to anything in the source and will be populated from elsewhere or left empty for now.
• Interactive source tree. The source side now renders as a tree: libraries as roots, folders as expandable children, up to four levels deep. Expand the parts you care about, leave the rest collapsed.
• Promote to site. Click a library or a folder in the source tree and promote it to its own target site collection. If a client has a sub-folder that is really a whole sub-business (“Finance/Acquisitions” on a mega-site), you can spin it off without restructuring anything else.
• Per-site target type picker. Each target site has a type: Microsoft 365 Group (Teams-connected), Communication Site, or Classic Team Site. Pick the right one per site, not one for the whole plan.

Folder-as-Source

The promotion feature is backed by a capability that did not exist before: the executor can now take a sub-folder of a source library and treat it as a source in its own right. When you promote HR/Benefits, the migration engine does not copy the whole HR library and then delete everything outside Benefits. It copies only the Benefits sub-tree into the new target library. The files underneath keep their relative paths, versions are preserved, and permissions are re-computed against the new target context.

This sounds obvious but it is the feature most restructuring engagements actually need. Real clients do not want “split this site along its group boundaries.” They want “take this folder, that folder, and the top half of this library, and make a new site out of them.” That is now a supported first-class operation.

Structure-Only Mode

There is one more new toggle that is worth explaining carefully, because it solves a scheduling problem we kept hearing about: the client wants the new site collections provisioned now, but the content migration has to wait for a change window.

Structure-only mode does exactly that. When enabled — as a global toggle, or as a per-site override if some sites should migrate content and others should not — the executor:

• Creates the target site collections.
• Creates the target libraries inside each site, with the renamed names applied.
• Applies the planned permissions.
• Does not copy any content.

The architect ends up with empty but fully provisioned sites ready to receive content. The client can review URLs, test Teams connections, wire up navigation, and do all the work that has to happen before files arrive. Then on cutover day the same plan runs again, this time with structure-only disabled, and only the content copy happens. Same plan, same targets, two passes.

The alternative — provisioning sites by hand and then running a migration that tries to create them again — tends to produce duplicate-name collisions, permission drift, and a bunch of manual cleanup. Structure-only mode keeps the plan as the single source of truth.

Concrete Scenarios

The combined feature set covers the four restructuring patterns we see most often:

1. Permission-based split. The site grew permissions over the years and now has ten distinct groups with barely overlapping access. Let the auto-analyzer propose sites along those boundaries, tweak a few names, execute. This is the case the old wizard already handled.
2. Content-based split. The site’s permissions are clean but the content is a mess. Use the source tree, promote the sub-folders that represent real business units, assign each to its own target, done.
3. Rename during restructure. The split is simple but the client wants to use the migration as a chance to rename everything to a new naming convention. Inline edits on every site and library mean the rename happens as part of the migration, not as a separate tenant-side project after the fact.
4. Structure-first, content-later. Provision the new architecture now, under Structure-only mode, so the client’s change management cycle has time to approve it. Run the same plan again during the cutover window with Structure-only off to move the data.

Where to Find Both Features

The Power Platform Inventory lives under the Governance section of the dashboard as a new scan type. It is included in the Copilot Readiness bundle at CA$1,599 and available as a standalone scan at CA$399. The free tier gives you one snapshot per tenant per month so you can see what it finds before deciding whether it belongs in your consulting workflow.

The Restructuring Wizard is part of the SharePoint migration workflow. Any existing MigrationFox account with a SharePoint credential can open it against a source site and start planning. There is no separate charge — the restructuring planner is part of the migration engine, and the migration itself bills on the same per-GB model as any other MigrationFox migration.

If you have not set up a Power Platform service principal before, start with the docs page at /docs/requirements/power-platform-inventory. The first scan takes less time than the setup. Every scan after that takes a few minutes.