A center that approves everything ends up owning everything
I have reviewed enough Power Platform programmes to have a rule about centers of excellence. The moment the center becomes the place every app has to pass through, it stops being the place makers go for help and becomes the place work goes to wait. Then someone in finance builds the same expense tracker in a spreadsheet with macros, and nobody in IT sees it at all. The center I would actually build is small, has a visible list of what it offers, and has an equally visible line where its responsibility stops.
The version that goes wrong is easy to recognise. A programme lead announces a center of excellence, staffs it with two people who were already busy, and gives it an intake form. Within a quarter the queue has forty items, the two people are answering the same question about Dataverse table permissions by email, and a maker whose flow has been waiting three weeks quietly rebuilds it in a personal environment. The center is now responsible for everything and in control of nothing.
Start with office hours and a short pattern library
The first thing I would stand up is a weekly hour where anyone can bring a half-built app or flow and get twenty minutes with someone who has shipped one. No form, no ticket, a calendar invite that is open to the whole tenant. In one programme I worked on, the office hour caught more real problems in its first month than the intake process had caught in a year, because people brought the thing they were stuck on rather than the thing they had described on a form.
The second thing is a pattern library, and I mean a short one. A solution template with the right publisher prefix and a connection reference already in it. An approval flow that writes its decision back to a Dataverse column instead of leaving it in someone's inbox. A Power Pages site template where table permissions are already scoped to the signed-in contact and anonymous access is off. Each pattern exists because someone got it wrong in a way that hurt, and the write-up says so plainly.
Makers copy a pattern when copying is faster than building from scratch. They do not copy it because a policy tells them to. If the template takes longer to find than a blank canvas app takes to create, the library is decoration. Fix the template before writing another one.
Give the risky questions a named route
Some questions should not wait for Thursday's office hour. A maker wants to connect a canvas app to the HR system's SQL database. Someone wants a Power Pages form that suppliers can submit without signing in, which means a Dataverse table with create permission for anonymous users. A flow is about to send customer records through a third-party connector that the DLP policy does not mention. These need an answer within a day, and they need it from someone who can actually say yes.
So the center publishes a short list of what counts as risky, and a single channel where those questions go, with a name attached. Once the list is written down, makers sort themselves. Most of what they build never touches it, and they stop asking permission for things that never needed it. The handful of questions that do arrive are the ones worth a senior person's attention. The lightweight review approach I would use for those fits in a thirty-minute call.
What the center does not do is approve. It advises, it can say no to the anonymous create permission, and it records what it said and why. The app still belongs to the maker, and the record of that conversation is what protects both sides when the auditor asks who agreed to what.
Count the repeated questions, not the meetings
The metric I would watch is dull. How many times did the same question arrive this month. If four people asked how to share a canvas app with a security group in the last thirty days, that is a pattern waiting to be written. If the number drops after the pattern is published, the center did its job. If office hours are full but the same questions keep arriving, the center is a help desk and needs to change what it produces.
The second number is how long it takes to find out who supports something. Pick a flow at random from the production environment and ask who gets called when it fails on a Sunday. In most tenants I have looked at, the honest answer for half the flows is the name of someone who left. A center that gets a support owner recorded for every solution in production, as a condition of promotion, has done more for the organisation than any number of reviews. The piece on where automation ownership breaks down covers what that record needs to say.
Meetings attended is a number I would refuse to report. I have watched a center present ninety review sessions a quarter to a steering committee that nodded, while the makers in those sessions were learning that the fastest way to ship was to avoid the center. Count what got easier for someone.
The maker keeps the solution
The biggest mistake is letting ownership drift to the center. It starts gently. A maker's Power Automate flow breaks after a connector update, the center fixes it because they were quicker, and now the center owns it, because that is who fixed it last time. Six months later the two people in the center are on the hook for thirty flows they did not build, and the office hour has quietly disappeared because there is no time left for it.
The rule I would write into the operating agreement is plain. The maker owns the solution until a support agreement says otherwise, and a support agreement is a document with a name and a date on it. If a solution matters enough that the business wants IT to run it, that is a handover, with a release checklist, a named support owner, and an environment the platform team controls. The center can help with the handover. It cannot be the destination for it.
This also settles the environment question. Personal productivity apps live in the default environment or a sandbox the maker owns. Anything with a support agreement moves into an environment with a deployment pipeline and a named admin. How many environments that means depends on the tenant, but the deciding question is always the same one: who answers when it breaks.
What to say when someone asks the center to take it over
Someone will ask, usually a director whose team built something useful and now wants it to be somebody else's problem. The line I use is this. The center will help you get the solution into a supported environment, will pair with your maker on the release, and will put a support owner's name on it. That owner sits on your side of the organisation unless IT has agreed to a handover in writing. Most directors accept that once it is said plainly. What they wanted was confidence that it would not fall over, and a named owner gives them that. A center that is quietly drowning does not.
If you are setting one of these up, or you have inherited one that has become a queue, the first move is to pull up the intake list and sort it into three groups: questions a pattern would answer, questions that belong on the risky-question route, and solutions that are waiting for an owner. Then go and cancel the form.
