Right now, somewhere in your organisation, there could be a business-critical process running inside a Power Platform environment you do not know exists. The app may have been built by someone who has since left. No documentation, no named owner, no backup plan. Working fine, for now.
It’s one of the most common things we find when organisations first take stock of their Power Platform estate. The platform has done what it was designed to do and let people solve problems quickly. What’s missing is enough structure to keep it working as it scales.
A Centre of Excellence is how you build that structure, but only if it’s set up the right way. The first 90 days decide whether your CoE helps people build well or ends up stalling adoption or being quietly ignored.
Start by avoiding the two most common mistakes
Most CoE programmes fail in one of two ways, at opposite ends of the same spectrum.
The first is over-governing early. Lengthy policy documents get written before anyone has mapped the estate. Multi-stage approval workflows get built for scenarios that don’t yet exist. Citizen developers encounter friction at every turn and quietly route around the whole thing. The CoE exists on paper, but the platform has moved on without it.
The second mistake is under-committing. The CoE gets announced, a steering group forms, and very little changes. The risks that triggered the conversation keep building, and without real authority or resource behind it, the CoE becomes a governance label rather than a functioning team. We look at the patterns behind stalled programmes in more detail in why most Power Platform Centres of Excellence stall.
Gartner has forecast that by 2026, developers outside traditional IT would make up at least 80% of low-code tool users. With that many non-IT builders, both failure modes get more expensive. The way through is a phased approach that builds confidence and earns credibility before adding complexity. Here’s how the first three months can look.
Days 1–30: Know what you actually have
The first 30 days shouldn’t produce a governance policy. They should produce an honest picture of the current state, because good decisions about what to govern depend entirely on knowing what’s out there.
Start with your environments and solutions
Use the Power Platform Admin Centre alongside the CoE Starter Kit to map what exists. How many environments are active? Which ones carry workloads the business would miss? How many solutions are unmanaged, sitting in personal environments, or tied to accounts that are no longer active?
This step usually turns up more than organisations expect. We worked with one team who discovered a critical finance approval flow still running on the personal account of a contractor who had left the previous quarter. Nobody had noticed because it had never broken. It was one password change away from a broken process with no recovery path. That’s what month one is for: turning invisible risk into something you can act on.
Then find out who is building and why
The people using Power Platform day to day know where the platform is adding real value and where it’s creating frustration. That conversation shapes the CoE’s early priorities more accurately than any framework document, and it builds goodwill with the people whose cooperation you’ll need later.
By day 30, the goal is a clear inventory, a realistic view of where the risk sits, and a short list of priorities that month two can act on directly.
Days 31–90: Build the structure, then make it visible
With a clear picture of the estate, the next two months focus on putting foundations in place and then demonstrating that they work. Keep the two together: people need to see the foundations working before they trust them.
Define your environment strategy first
A three-tier model works well for most organisations: a personal tier for individual experimentation, a shared development and test tier for team solutions, and a production tier for business-critical workloads. Each tier needs clear criteria for what belongs there and how solutions move between them.
Three environments with well-understood rules will serve you better than ten environments with blurry ones. The aim is a model people can follow without asking every time. It’s also the first building block of a wider low-code operating model that keeps working as adoption grows.
Connector governance deserves specific attention
Blanket restrictions are one of the fastest ways to undermine adoption, and they rarely improve security in practice. A simple three-category approach covers most needs: connectors available by default, connectors that require a short review before use, and connectors that are blocked. The blocked list should be short and well-reasoned. If getting a connector approved takes weeks and multiple sign-offs, people will find a way around it, and you’ll lose sight of what’s being connected to what.
Give every high-risk solution an owner
Every high-risk solution identified in month one should have a named owner and a named backup by the end of month two. That means someone accountable for the solution over time, not just the original developer. This is also the right moment to define the CoE team itself: who holds the admin function, who manages incoming requests, and who owns the relationship with business stakeholders. A small team with genuine authority will get further than a large steering group that meets quarterly.
By months two and three, make the CoE visible
Microsoft’s Power Platform CoE Starter Kit provides dashboards and compliance reporting that would take months to build from scratch. Configured well, it gives leadership a live view of the estate: active solutions, usage trends, and where the high-risk assets are. Showing that dashboard in a leadership meeting, answering the questions that have been circulating informally for months, does more for the CoE’s credibility than any presentation about governance strategy.
Publishing the first standards in this phase matters too. Naming conventions, a simple intake process for new business-critical workloads, and guidance on when to use Dataverse rather than SharePoint as a data layer. These should be concise enough to absorb quickly and clear enough to follow without interpretation. Governance that requires a guide to understand doesn’t get used.
Running the first internal enablement session, even something as informal as a lunch-and-learn covering environments and connectors, signals that the CoE exists to help people build well, not to make it harder. That message matters more than any policy document.
Governance that sticks without slowing things down
By month three, the CoE should have real visibility of the estate. Named owners for the highest-risk assets. An environment strategy that people are following. A set of standards that are live and accessible. None of that requires months of process or heavyweight approval layers.
The bigger risk at this stage is the instinct to over-correct once risks become visible. When problems surface, the response is often to add more governance: more approval stages, more centralised control, more policy covering scenarios that haven’t happened yet. It all feels responsible, and it usually produces the same result: adoption slows, the most active citizen developers disengage, and the business starts solving problems in ways the CoE can’t see.
We’ve seen this play out directly. One organisation spent the first four months of their CoE programme building a comprehensive governance framework before any structural basics were in place. By the time it was ready, two of the three internal champions had moved on to other priorities. When they reset with a lighter-touch approach, focused on environments, ownership, and visibility, they made more progress in six weeks than they had in the previous four months. The framework itself was fine. The sequencing was the problem.
The right approach is to govern what’s genuinely risky, enable what’s clearly safe, and measure what’s being built before trying to optimise it. Licensing optimisation, reusable component libraries, AI governance policies (see governing AI agents at enterprise scale and Copilot Studio governance): these are all legitimate next steps, and the CoE will be ready to take them on as it matures. Trying to build them all in the first 90 days is the surest way to arrive at month three with a framework and very little to show for it.
A CoE that people trust gets used. One that feels like a gate gets bypassed.
How Flyte can help
Flyte helps organisations get more from Power Platform, and setting up a Centre of Excellence is often part of that.
We help organisations define the right starting point based on where they actually are, not where a generic framework assumes they should be. That usually means shaping the discovery phase, designing an environment strategy that fits the organisation’s licensing and risk profile, and deploying the CoE Starter Kit in a way that delivers real visibility quickly. For organisations that want ongoing help, our Complete support package includes a fully operational Microsoft CoE.
If adoption is accelerating and the governance questions are getting harder to put off, get in touch. We’ll help you work out the next step and build a practical plan, without governing for a future that hasn’t arrived. If you’re not sure whether you’re ready for outside help, our guide on how to know you’re ready to bring in external help with Microsoft Power Platform is a good place to start.
The goal is a CoE that gives your teams room to build, with guardrails that protect the business as they do.