Power Platform Governance Without the CoE Starter Kit

This post explains how to govern Microsoft Power Platform now that Microsoft has stopped actively maintaining the Center of Excellence Starter Kit. It covers what the four native governance controls actually are (environment strategy, ownership, data policies, and lifecycle management), which of them are free and which sit behind premium licensing, why app and flow sprawl is the default state of every tenant rather than a configuration failure, and where native tooling stops working and human decisions have to take over. If your organization has been treating a CoE Starter Kit deployment as the governance project, or has been putting governance off because the kit looked like too much work, the ground has moved under both positions.

For years the assumption was that serious Power Platform governance meant deploying the CoE Starter Kit. It was never an official product. It was a set of sample apps, flows, and dashboards that organizations installed, licensed, and maintained themselves.

That assumption is now out of date. Microsoft’s documentation states the kit is no longer actively maintained, that its core capabilities have moved into the Power Platform admin center, and that reported issues are no longer reviewed or addressed. Existing deployments keep running. They just stop getting better, while the platform underneath them keeps changing.

For a decision-maker this collapses a long-running debate into a short one. The question is no longer whether to deploy the kit. It is whether you know what is running in your tenant, who owns it, and what happens when that person leaves.

Before any control gets configured, find out what you actually have.

Power Platform inventory reached general availability in March 2026 and gives tenant administrators a unified view of cloud flows, agent flows, and workflows across every environment. Administrators can discover, search, filter, and sort apps, flows, and agents across the organization.

This matters more than it sounds. The most common finding in a first governance assessment is not a policy gap. It is that nobody in the organization could say how many apps and flows existed, or who was responsible for them. Every control decision that follows depends on that number.

Run the inventory first. Decide what to control second.

Environment Strategy

The Default environment is where sprawl starts, by design. A single default environment is created automatically for every tenant and shared by all users in it. Whenever a new user signs up for Power Apps they are automatically added to the Maker role of that environment. It cannot be deleted.

So every licensed user in your organization can build there today, with no admin action and no request.

You can restrict who creates new environments. Tenant settings in the Power Platform admin center let you limit environment creation to specific admins, applied separately for each environment type. Two honest caveats. Environments created before the restriction remain manageable by their creators after it is applied, so this stops the bleeding rather than cleaning the wound. And while you cannot block access to the Default environment, you can minimize what happens in it, mainly by routing makers elsewhere.

Environment groups and environment routing are generally available. Routing directs new makers to personal developer environments instead of the shared Default one. Note the licensing consequence before you switch it on: all developer environments created through environment routing are managed environments by default, which pulls the premium licensing requirement in with them.

Ownership

This is where governance quietly fails, and it is the least visible of the four.

An orphaned flow is one that no longer has a valid owner. These flows can fail if they use connections tied to the departed user’s account. Admins can reassign them, either through the Resources tab in the admin center or through PowerShell for larger volumes.

The failure mode is worth understanding precisely, because it is delayed. Nothing breaks the day the owner leaves. The flow keeps running until the stored authentication behind it stops working. Then a business process stops, and the person who understood it is gone.

That second part deserves more attention than it usually gets, because a departure is only one of the things that breaks a connection.

A connection stores the credentials it was built with. Change the password on that account and the existing connection using the old password is invalidated. Roll out multifactor authentication or tighten a Conditional Access policy and existing tokens may no longer satisfy the new requirement, so the connection needs reauthorizing. Revoke an app consent and the same thing happens. Even inactivity is enough: refresh tokens expire after roughly 90 days without use, so a flow that runs quarterly can fail simply for having waited too long between runs.

Read that list again and notice what it has in common. Every item is a routine security improvement. The organization tightens identity controls on Monday and a finance reconciliation stops on Tuesday, with no obvious connection between the two. This is the version of the problem that generates a support ticket nobody can diagnose.

Service accounts are the usual answer, and they are better than a named employee, but they are not immune. A service account is still subject to password policy and still subject to Conditional Access. Where a connection runs on a service principal instead, it does not depend on any user’s token and does not break when somebody changes a password or leaves, though the client secret behind it still expires and still has to be rotated.

The governance point underneath all of this: for anything a department genuinely depends on, the identity behind the connection is a decision to make deliberately, not a by-product of whoever happened to build the flow.

Where licensing is the issue rather than departure, a flow assigned to a new owner continues running for 30 days to allow time for a license to be purchased. After that grace period Power Automate turns it off.

Data Policies

Data policies, formerly called DLP, are the security control most organizations already have and most overestimate.

Connectors are categorized as Business, Non-Business, or Blocked. Business connectors can connect only to other Business connectors, and Blocked connectors are prevented entirely. A connector can sit in only one group at a time.

Here is the limit that matters. There is no specification as to the type of data you can share over a connector. If a maker has access to a SharePoint connector, they can reach the content of a library regardless of what is in it. Data policies govern which connectors can combine. They do not inspect what moves through an approved one.

There is a second limit. Some connectors cannot be blocked by data policies at all, including Dataverse connectors, because Dataverse is integral to the platform. Advanced connector policies use a strict allowlist model and can restrict certified connectors including these non-blockable ones.

Lifecycle Management

Apps built directly in the Default environment, outside a solution, are difficult to move, version, or deploy cleanly. That is the mechanical reason sprawl becomes unsupportable rather than merely untidy. It is not that there are too many apps. It is that the important ones cannot be moved anywhere.

A solution is the container that makes an app portable. Components built inside one can be exported as a unit, moved between environments, versioned, and deployed through a repeatable process rather than rebuilt by hand. Components built outside one are tied to the environment they were created in.

For a decision-maker the practical consequences are worth spelling out. An app in a solution can be tested somewhere other than production, which means changes stop being deployed live to the people relying on them. It can be rolled back when a change goes wrong. It can be handed to a different person, or a partner, without a reconstruction exercise. And it can be source controlled, which turns an app that lives in one person’s head into an asset the organization owns.

Pipelines provide that promotion path in the product, and Azure DevOps and GitHub integrations cover teams that want full source control.

None of this needs to apply to everything. A personal flow that moves somebody’s email into folders does not warrant a deployment pipeline. The test is dependency: if a team would notice within a day that it had stopped, it belongs in a solution. That distinction is cheap to make early and expensive to retrofit, which is why it is worth deciding before an estate grows rather than after.

Two rows deserve emphasis.

If your maker population is broad and mostly running on Microsoft 365 seeded rights, turning on the strongest native governance across that population changes your licensing position. Model it before you commit.

Nobody misconfigured anything. A user with a Microsoft 365 license can build in the Default environment on day one. The environment cannot be removed. Every new user joins the Maker role automatically.

Sprawl is what the platform does when left alone. Treating it as a discipline problem, or as evidence that someone should have deployed a governance tool sooner, gets the diagnosis wrong and usually delays the fix.

There is one thing no tool in this article does. It cannot tell you which of your apps matter. Inventory shows you what exists. Advisor flags what looks risky. The actions page surfaces apps without valid owners and apps unused in the last 60 days. None of that decides whether the unused app is dead or seasonal, or who should own it now, or whether retiring it will break something in finance.

That part is a human decision, and it is the part organizations skip.

Inventory the estate. Restrict environment creation. Author a tenant data policy. Those three cost nothing but attention.

Then make the decision that actually costs money: which environments warrant Managed Environments, and what the licensing implication is across the users in them.

If your CoE Starter Kit deployment is still running, it is not urgent, but it is now a dependency with no roadmap. Plan the transition to native admin center capabilities on your schedule rather than on the schedule of whatever breaks first.