← Back to Blog

GOVERNANCE · April 12, 2026 · Updated April 24, 2026 · 12 min read

Power Platform Governance Assessment: The Shadow IT Layer Most Tenants Forget

Microsoft Power Platform is the layer of Microsoft 365 that grew up while IT was looking somewhere else. Power Apps for end users started as a "build a small form, no code required" tool. Today the median enterprise tenant has 40-plus environments, hundreds of apps, thousands of flows, and dozens of premium connectors — and the governance team finds out about all of it the day a maker leaves the company and IT inherits a critical app nobody can edit.

The Power Platform Assessment is the read-only audit that finds the sprawl before it becomes an outage. It pulls a full tenant inventory through the Power Platform Admin (BAP) API, the Flow admin API, and Dataverse — then correlates flows, apps, and connectors against your DLP policies to surface the artifacts that are silently broken, invisible from the Power Apps portal, or about to fail the day Copilot goes live.

What the Assessment Audits

A single scan produces five data slices plus one correlation layer. Everything is fetched read-only with a service principal you already use for governance assessments — no agents, no forwarders, no PowerShell running on your side.

Environment inventory

Every environment in the tenant via api.bap.microsoft.com/providers/Microsoft.BusinessAppPlatform/scopes/admin/environments — production, sandbox, trial, developer, default, and teams environments. Per environment, the report records display name, region, SKU, created-by, created-date, Dataverse database presence, and last-activity signals. Anything over 10 environments in a tenant under 5,000 users is sprawl. Trial environments older than 90 days that nobody owns are the canonical "47 trial environments nobody owns" failure mode, and they fall out of this inventory on the first scan.

DLP policy analysis

Every Data Loss Prevention policy in the tenant via GET api.bap.microsoft.com/providers/PowerPlatform.Governance/v2/policies, with each policy hydrated from its detail endpoint to populate the Business / Non-Business / Blocked connector buckets. Missing and mis-classified policies are the single most common data exfiltration path in a Power Platform tenant — the canonical misconfiguration is social connectors classified as Business Data so they can be combined with SharePoint connectors in a single flow. The assessment renders each policy's three buckets side-by-side so the misclassifications are obvious at a glance.

Flow inventory

Every Power Automate flow in every environment via api.flow.microsoft.com/.../admin/environments/{env}/v2/flows, enriched per-flow to pull real connectionReferences. Per flow, the inventory captures owner email, state (started / stopped / suspended), trigger type, modified date, and the full connector list. Orphan flows (owner left the tenant), stopped flows with active connection references, and flows that haven't run in 90+ days all surface here — the same hygiene a SharePoint governance assessment catches, but for the Power Platform surface.

App inventory

Every canvas and model-driven Power App in every environment via api.bap.microsoft.com/.../admin/environments/{env}/powerApps, with per-app enrichment for connector references. Owner email, display name, app type, modified date, and connectors used. Same orphan and staleness signals as flows.

Dataverse solution inventory

For every environment with a Dataverse database, every solution via {dataverseUrl}/api/data/v9.2/solutions — unique name, friendly name, version, publisher, managed or unmanaged. Surfaces the managed solutions nobody remembers installing and the unmanaged solutions that quietly accumulated over three years of citizen development.

Tenant-wide connector usage matrix

The correlation layer that ties everything together. Every connector referenced by any flow or any app in the tenant is aggregated into a single matrix, sorted by total reference count, with pills for Premium, Business-classified, Non-Business-classified, and Blocked. Rows where a connector is Blocked by DLP but still has non-zero references are highlighted in red — those are the flows and apps that stopped running the moment DLP was enforced, and the owner doesn't know yet. This is the finding that pays for the assessment by itself.

What It Catches That the Admin Portal Does Not

The Power Platform Admin Center is excellent for poking around interactively. It is not designed to answer "produce a prioritized list of governance gaps in five minutes" because everything is screen-by-screen and nothing correlates across environments. The assessment surfaces the findings that require cross-environment joins:

Silently broken flows. A connector moves from Business to Blocked in a DLP policy. Every flow that references it stops running. The maker doesn't get an email. The assessment lists those flows by owner, by environment, by last-run-date.
Orphan ownership. Flows and apps whose creator is no longer in the tenant. The admin portal shows owner emails one at a time; the assessment cross-references every owner against the directory in one pass.
Premium connector sprawl. Every premium connector used anywhere in the tenant, which flows and apps reference it, and the environment it lives in — so licensing compliance is visible before an audit.
DLP coverage gaps. Environments that exist but have no DLP policy applied to them. The matrix makes coverage explicit per-environment instead of per-policy.
Managed solution drift. Dataverse solutions installed across environments with different versions — the classic "staging has 2.4, prod has 2.1" compliance gap.

Graph-Level Signals That Accompany the BAP Audit

Alongside the BAP inventory, the assessment runs four Microsoft Graph checks that contextualize the footprint against the rest of the tenant:

Power Platform license detection

/subscribedSkus is scanned for every Power Platform SKU variant: POWERAPPS_PER_USER, FLOW_PER_USER, POWER_BI_PRO, POWER_BI_PREMIUM_PER_USER, the GCC government variants, developer SKUs, and trial SKUs. Case-insensitive matching with an explicit allow-list avoids false positives on Dynamics 365 SKUs that share name fragments. PP-002 fires with the detected variants; PP-001 fires if no Power Platform SKUs are visible despite other signals of Power Platform usage (some Power Apps entitlement is bundled into M365 base SKUs and is not visible in /subscribedSkus).

Service principal inventory

/servicePrincipals is filtered to known Power Platform display names: PowerApps Service, Microsoft Power Automate, Microsoft Dataverse, Common Data Service, Power BI Service, Microsoft Power Platform Admin Center. If any are present — even with zero SKUs detected in the prior check — Power Platform is in use. PP-003 fires with the SP count.

OAuth permission grants

For each Power Platform service principal, /oauth2PermissionGrants confirms user consent. Catches the edge case where a service principal exists in the tenant but no users have ever consented to it — common in tenants where Power Platform was provisioned for a single department and never used broadly.

Conditional Access targeting

Power Platform service principals are cross-referenced against every Conditional Access policy. A tenant where Power Platform is in active use but no CA policy targets the Power Platform service principals is a tenant where Power Apps users can sign in without MFA — even if the rest of the tenant has 100% MFA coverage. PP-009 (connection health) extends this by flagging service-principal-authenticated connections missing from sensitive-resource CA scope.

Roadmap

The current release covers the governance checks that ninety percent of tenants need on day one. On the roadmap:

Every item on the roadmap builds on top of the inventory that ships today — none of it is required for the assessment to deliver a full tenant picture in a single scan.

Scan Scope

A single scan covers up to 30 environments for flow + app enumeration, up to 25 environments for Dataverse solution enumeration, and up to 150 flow-detail + 150 app-detail enrichments for connector reference hydration. Tenants with more environments get the most recently modified first, and additional scans can be run with filters for specific environments. Missing tier grants (for example, per-environment Application User records) degrade gracefully — the scan still completes and a Scan Diagnostics panel explains exactly which tier needs to be granted, so the second scan returns the missing data without re-running the whole audit. Full access tier reference in the Power Platform Inventory docs.

Why This Pricing Tier Exists

The Power Platform admin tooling market splits into three buckets:

The Power Platform Assessment at CA$399 sits in the empty slot: a full BAP API inventory of every environment, flow, app, connector, solution, and DLP policy, correlated into a single tenant-wide connector usage matrix, exported as PDF / JSON / HTML / CSV in five minutes. It does not replace a CoE practice — it tells you whether you need one.

How to Run It

Free Snapshot first — view-only score, four-state verdict, one sample finding, one snapshot per tenant per month per product, no credit card. For the full inventory with all five data slices, the connector usage matrix, and 90 days of JSON / HTML / CSV / PDF exports, the CA$399 single assessment unlocks it. The CA$1,599 Microsoft 365 Complete Bundle includes Power Platform plus all 5 other assessments and ships with white-label PDF and a commercial redistribution license.

Power Platform Assessment

CA$399 one-time

90-day access · 1 tenant · Full BAP + Flow + Dataverse inventory · Connector usage matrix

Buy CA$399 →

Or run a Free Snapshot first — no credit card

Read more: Power Platform Assessment product page · Power Platform Inventory docs · Copilot Readiness deep-dive · The Complete Bundle