Ask ten organizations what their Power Platform Center of Excellence is, and you will get ten answers. A dashboard. A committee. A SharePoint site. A person who knows where the apps are.
Most of them are describing the artefacts of a CoE, not the CoE itself. A Center of Excellence is not a thing you install. It is an operating model: a mandate, a set of roles, decision rights, an intake process, and a rhythm. The dashboard is just how you see it working.
The organizations whose CoEs actually work share a pattern. It is not complicated — but it is specific, and it is worth stating plainly.
Consider a familiar story. An organization installs the CoE Starter Kit, builds a dashboard, and declares the CoE established. The dashboard shows apps and flows. Nobody looks at it. A maker requests a production environment and waits three weeks for a committee decision. The maker builds in the default environment instead. Six months later, an audit finds business-critical apps with no owner, and the CoE — the dashboard — had nothing to say about any of it.
That CoE did not fail because the tooling was wrong. It failed because nobody answered the operating questions: who decides, who owns, what happens when a maker needs something, and what does the CoE do when it finds a problem. The dashboard answered none of those. It only displayed the consequences of not answering them.
This is the most common CoE failure mode: mistaking visibility for governance. Visibility is necessary. It is not sufficient. Governance is what happens after you see the problem.
A CoE without a mandate is a suggestion box. The mandate has to answer three questions: what decisions does the CoE own, what can it stop, and who backs it when a business unit disagrees? If the CoE cannot stop an app from going to production, it does not govern — it observes.
The mandate should be short, written, and signed by someone with authority over both IT and the business. One page is enough. Zero pages is not.
Writing the mandate forces the conversation that most organizations avoid: does IT actually have the authority to govern citizen development, or does it merely have the responsibility? If the answer is responsibility without authority, the CoE will fail no matter how good the tooling is. Get the authority question settled first, in writing, with a signature from someone who can enforce it.
Successful CoEs define a small set of roles: a platform owner, environment administrators, a DLP and security contact, and maker champions in the business. The roles are named, documented, and — critically — not dependent on any single person. A CoE that collapses when one person goes on leave was never a CoE.
The hero trap is real. Every organization has someone who understands the platform deeply and holds the whole thing together through personal effort. That person is an asset — and a risk. If the CoE depends on them, it is not an operating model. It is a person with a title. Document the roles, distribute the knowledge, and make sure every critical function has a backup who has actually performed it.
The intake process is where governance meets reality. If requesting an environment takes three weeks and a form that asks for architecture diagrams, makers will route around it — and you will have shadow IT with extra steps. Good intake is fast for low-risk requests, rigorous for high-risk ones, and transparent about where a request stands.
The test is simple: can a maker get a sandbox environment in a day, and a production decision in a week? If not, the process is the problem.
Design intake around risk tiers, not uniform rigor. A personal productivity app in a sandbox needs a notification, not an approval. A production app touching sensitive data needs a security review, a named owner, and an ALM plan. Treating both the same way guarantees that makers will bypass the process for the easy cases — and then bypass it for the hard ones too, because the habit is already formed.
The CoE Starter Kit gives you inventory and usage data. That is the raw material, not the product. The product is a regular review — monthly is enough — where the CoE looks at what is being built, what is orphaned, what is risky, and decides what to do about it. A dashboard nobody reviews is decoration.
The review meeting is where governance happens. It needs an agenda: new apps and flows since last month, orphaned items and their disposition, DLP violations and their resolution, environment requests and their status, and one improvement to the platform each month. Without that meeting, the CoE is a reporting tool. With it, the CoE is a governing body.
The most important function of a CoE is the one most organizations miss: a graduation path. When a citizen-developed app becomes business-critical, there has to be a way for it to become a governed, supported solution — with ownership, ALM, and a support model. Without that path, business-critical apps stay in personal environments, owned by nobody, until they break.
Graduation should feel like a promotion, not a punishment. The maker gets support, documentation, and a production environment. The organization gets a governed asset. The alternative — the app staying in a personal environment because the maker fears losing control — is how business-critical processes end up depending on solutions nobody can maintain.
Building a CoE does not require a large program. Ninety days is enough to establish the operating model. The first month settles the mandate and the roles — the written authority, the named people, the decision rights. The second month establishes visibility and intake: the Starter Kit configured, the inventory baselined, the intake process live with risk tiers. The third month runs the first real review meeting and graduates the first app through the path to production. After ninety days, the CoE is not a project. It is a routine.
A working CoE produces signals you can observe. Makers use the intake process instead of routing around it. Orphaned apps get claimed or archived within a month of being flagged. DLP violations trend down, not because enforcement weakened but because makers understand the boundaries. The monthly review meeting makes decisions that stick. And when an auditor asks about the platform, the answer comes from the CoE's records — not from a scramble.
A CoE does not need to be large. For most organizations, it is a handful of people and a few hours a week. What it needs is a mandate, roles, intake, reporting, and a graduation path — in that order. Everything else is configuration.
Book a scoping call to design a CoE that fits your organization — mandate first, tooling second.