Centre of Excellence is one of the most used phrases in every Power Platform conversation and one of the least examined. Organisations decide to establish one. Consultants recommend one. Microsoft's own documentation prescribes one. And then, in a significant number of programmes, nobody is named as the owner before the build starts.

The consequence is not visible immediately. Environments get created, apps get built, flows go live. The platform grows. Makers proliferate. And without a named owner, without defined responsibilities, without governance that was agreed before the first solution was deployed, what was supposed to be a controlled programme becomes an estate that nobody fully understands.

A CoE is not a dashboard. It is not a toolkit. It is not a project phase that gets delivered and closed. It is an operating model, and like any operating model, it only works when the people who are supposed to run it have been named, resourced, and given clear accountability before the platform scales.

The single most common CoE failure is not a technology gap. It is the absence of a named owner before the programme begins. Everything else follows from that.

What a CoE Actually Is

Microsoft defines a Centre of Excellence as a team or entity that drives innovation and improvement and provides leadership, best practices, research, support, and training for Power Platform across the organisation. That is a reasonable definition, but it describes the output rather than the structure.

In practice, a CoE is the answer to four organisational questions that every Power Platform programme eventually has to answer:

1. Who decides what gets built, in which environments, and against which data sources?

2. Who owns the platform standards that govern how makers work?

3. Who is responsible for an app or flow when its original maker leaves the organisation?

4. Who ensures that the platform remains compliant, secure, and fit for purpose as it grows?

When these questions are answered upfront, with named owners and defined processes, the CoE functions as designed. When they are deferred until after build, they are answered by default. The default answer, in every case, is that nobody owns it.

What Happens Without a CoE

The pattern of ungoverned Power Platform growth is well documented and remarkably consistent across organisations of different sizes and sectors.

It starts with genuine success. A team builds a useful app. It solves a real problem. Other teams see it and want something similar. Maker activity grows. Environments multiply. Flows are built to connect systems that were never intended to be connected. At each step, the individual decisions are reasonable. Cumulatively, they produce an estate that has grown beyond what any single team can see or manage.

The research findings are striking. Organisations without formal CoE governance experience application sprawl, security violations, and compliance breaches at rates three to four times higher than those with established Centres of Excellence. Rescue engagements routinely uncover 40 to 60 percent more Power Platform assets than IT leadership estimated existed. In one documented case in the aerospace sector, 47 percent of Power Apps had no documented owner after their original creator left the organisation. The apps continued running, processing business-critical data, while no one could explain their logic, security model, or data sources to an audit team.

DLP policy remediation in an ungoverned environment is particularly costly. Changing connector classifications in a live tenant can immediately break production apps and flows, forcing a triage exercise before any governance improvement can be applied. The technical debt compounds with every week the CoE is deferred.

The orphaned app problem

When a maker leaves an organisation, their apps and flows continue to run. They continue to access data. They continue to process transactions. But without a named owner, no one can modify them, support them, or decommission them safely. In regulated environments, this creates audit exposure that cannot be resolved without rebuilding governance from scratch.

What Ownership Actually Means

Ownership in the context of a CoE is not a job title. It is a set of specific accountabilities that need to be held by named individuals before the platform is deployed at scale. The following table sets out the roles a functional CoE requires, and what each one actually means in delivery terms.

Not every organisation needs a full-time person in each of these roles, particularly at the outset. What every organisation needs is a named person in each role, with agreed accountabilities, before the first production solution is deployed.

The Five Things a CoE Must Govern

Ownership without defined scope produces meetings, not governance. A functional CoE has clear accountability for the following five areas.

1. Environment Strategy

Every Power Platform programme needs at minimum a development environment, a test environment, and a production environment per workstream or domain. The default environment is not a governed space: every licensed user can create apps and flows in it, against any data source, with no controls. Deploying production solutions into the default environment is the single most common governance error in Power Platform programmes.

The CoE owns the decision of how many environments exist, who can create them, what purpose each serves, and what DLP policies apply to each. Managed Environments, available in premium licences, add admin controls and governance telemetry that are not available in the base tier, and the CoE should define where these are applied.

2. DLP Policy Design and Maintenance

Data Loss Prevention policies control which connectors can be combined in a flow. They are not a one-time configuration. Microsoft regularly adds new connectors, and each new connector requires a classification decision. A DLP policy that was correctly designed at programme launch will drift from its intended state if it is not actively maintained.

The CoE owns the DLP policy framework: which connectors are classified as business, which are non-business, and which are blocked. It also owns the process for reviewing and approving new connector requests from makers, which is a governance function that must be embedded in the operating model rather than handled ad hoc.

3. Maker Governance and the Intake Process

One of the most consequential CoE design decisions is whether to run an open or gated maker model. An open model allows any licensed user to build. A gated model requires makers to register, complete training, and build within defined environments before they can deploy to production. Neither extreme is universally correct. Most mature organisations operate a hybrid: open for personal productivity and experimentation, gated for anything that touches shared data or production systems.

The intake process is the mechanism by which new maker requests, new use cases, and new connector requirements are assessed, prioritised, and approved. Without it, the CoE has no visibility into what is being built until it is already live. With it, the CoE can sequence delivery, manage capacity, and ensure that what gets built meets the organisation's standards before it enters production.

4. Solution Lifecycle Management

Every production app and flow needs a named owner, a support path, and a lifecycle plan. The lifecycle plan does not need to be elaborate. It needs to answer three questions: who supports this solution if there is a problem, who can make changes to it, and how does it get decommissioned when it is no longer needed.

The CoE owns the process for capturing this information at the point a solution enters production, and for maintaining it as makers move roles or leave the organisation. Orphaned apps, where the original maker has left and no successor owner has been named, are the most acute governance risk in a scaled Power Platform estate. The tooling to detect them exists natively in the Power Platform Admin Centre. Acting on what the tooling surfaces is a CoE function, not a technical one.

5. ALM and the Deployment Pipeline

Application Lifecycle Management defines how solutions move from development through testing to production. Without ALM, solutions are typically exported and imported manually, without version control, without a test record, and without a rollback mechanism if something goes wrong in production.

The CoE owns the ALM design: whether to use Power Platform Pipelines, Azure DevOps, or a combination of both; the branching strategy; the approvals process for production deployments; and the standards for solution packaging that ensure solutions can be promoted without environmental dependencies breaking the deployment.

The Right Time to Establish a CoE

The most common answer to this question is: after the first major programme is live, once there is something to govern. This is the wrong answer, and it is expensive.

The right time to establish a CoE, or at minimum to name its roles and define its scope, is before the first production environment is created. Not because governance for its own sake is valuable, but because the decisions taken in the first weeks of a Power Platform programme, about environment structure, DLP policy, maker access, and solution standards, create the patterns that every subsequent decision is built on. Retrofitting governance onto a mature estate means not just applying standards to new solutions, but remediating everything that pre-dates those standards.

Organisations that defer CoE establishment until the platform has scaled consistently report the same outcome: the remediation cost significantly exceeds the cost of governance that was applied from the outset. The asset rationalisation alone, removing duplicate apps, retiring orphaned flows, and restructuring ungoverned environments, typically reduces the active Power Platform estate by 40 to 60 percent. That is 40 to 60 percent of solutions that required build effort, support effort, and licensing spend, and then required further effort to clean up.

Three questions to answer before the first production environment is created

Who is the named CoE Lead with organisational mandate and budget authority?

What is the environment strategy, and what DLP policies apply to each environment from day one?

What is the intake process for new maker requests, and who approves new connector classifications?

A Note on Tooling

Microsoft's CoE Starter Kit, a collection of Power Apps, Power Automate flows, and Power BI dashboards designed to provide governance visibility and maker management, was announced as no longer actively maintained as of May 2026. Microsoft is directing organisations to the Power Platform Admin Centre (PPAC) as the primary governance experience, with native inventory, usage, and monitoring capabilities.

The PPAC provides visibility: it shows what exists in a tenant, who built it, and how widely it is used. What it does not do is make the governance decisions that visibility surfaces. Deciding who owns a widely shared app when its maker has left. Determining whether a flow processing sensitive data should remain in its current environment. Resolving a connector classification that is blocking a legitimate use case. These are organisational decisions, not platform configurations. They require the CoE structure and the named roles that sit within it.

Tooling supports governance. It does not replace the operating model that governance requires.

CoE at Different Scales

A common objection to formal CoE establishment is that it is disproportionate for smaller programmes. This is a reasonable concern, and it is worth addressing directly.

At small scale, a CoE does not require a dedicated team. It requires named individuals with defined accountabilities. A single Power Platform Admin who also owns DLP policy, and a named business sponsor who approves governance decisions, is a functional CoE for a programme with fewer than a dozen active makers. The discipline of naming those roles and agreeing those accountabilities upfront is what matters, not the headcount.

At enterprise scale, Microsoft's customer data provides useful benchmarks. Organisations with thousands of active makers and thousands of environments have operated with small centralised governance teams, using Managed Environments and telemetry to maintain visibility without a proportionally large CoE staff. The critical enabler in every case is not team size. It is that the governance model was designed and operating before the estate grew to the scale that made it difficult to manage.

What a Mature CoE Produces

The output of a well-run Centre of Excellence is not compliance documentation. It is a platform that continues to deliver value as it scales, without the remediation cycles and governance crises that characterise ungoverned growth.

Makers build faster because there are standards and templates to build from, rather than every solution being designed from scratch. IT teams spend less time firefighting because problems are caught at the intake and review stage rather than in production. Business leaders have confidence in the platform because the data that flows through it is governed, auditable, and owned.

The organisations that achieve this are not the ones that invested more in tooling. They are the ones that invested in naming the owner before the programme started.

About VE3

VE3 is a technology and consulting partner working with UK public sector and enterprise organisations on Microsoft Power Platform, automation (RPA), and Centre of Excellence programmes. Our discovery-led approach establishes governance foundations before build begins, ensuring programmes scale without the remediation cycles that characterise ungoverned growth. To discuss our Power Platform CoE design and readiness framework, contact your VE3 representative.