How to structure a Salesforce center of excellence for enterprise companies
A centre of excellence owns the standards, the intake, and the refusal. A ticket queue with the same name will be routed around.
Platform & ArchitectureA senior request arrives on a Thursday: make the demo answer. The centre of excellence is a queue. The next review is in three weeks. The builder changes production that afternoon, because a queue that cannot say no is slower than an apology. The permission set is wide enough that the agent can see records the seller cannot. The architect, who visits monthly, sees the slide the following month and nods. The add-on the action needs was never on the intake form. In the second week the usage the team did not look up is the thing that stops the job. The apology is already in the ticket.
A centre of excellence is the group that can keep an enterprise org from becoming a pile of local exceptions. It owns the standards, the front door, and the refusal. If it only queues tickets, builders will route around it. The route around is the design you will actually be running.
What it owns
Standards: how objects are named, how automation is reviewed, what done means for a change, and which things a local admin may configure without a design. Write them where builders already look. A page in the tool they use, or a short note in the repository they commit to. A standard that lives in a slide from last year's offsite is not a standard. It is a memory, and the next project will not open it. If a builder cannot find the rule in the minute before they build, the rule does not exist yet.
Intake: one front door. The form asks which process hurts, which object it touches, and which person will own the result after the project team leaves. A request that names neither the process nor the object goes back. So does a request that is only a product name. "We need an agent" is not an intake. "Cases in this queue take a second call because the product is blank" is an intake. The form is how you refuse to start from the demo.
The no: a recorded decision when a request would fork a standard, duplicate a field, or add a flow on an object that already has an owner. Recorded means the asker can read the reason, the standard it cites, and what would have to be true for the answer to change. A verbal no in a meeting that is not written down will be re-asked next month as if it were new. If the group cannot say no, it is a mailbox with a steering title, and the org will fill with the requests that were easiest to build.
Publish the last ten decisions, yes and no, where the next asker will see them. Patterns show up. Five requests for a new stage field are one argument about the definition, not five builds. The centre's job is to notice that before the fifth field exists.
Architects sit in the intake
An architect who visits once a month sees the slides the team prepared. An architect who sits in intake sees the request before it becomes a flow. That is the difference. Slides are what survived. Intake is what is about to be built, including the version that grants wide access so a workshop can finish. The architect in the room can send that version back the same day. The architect in next month's meeting can only write a finding.
The work arriving now includes agents. Salesforce says: "Businesses can build agents with Agent Builder using existing Salesforce Platform tools to create standard and custom subagents and actions." Someone in the room has to be able to read that request, put the action on the right object owner, and refuse the version that grants wide access so a demo can finish. The running user, the fields, and the object owner are the design. A committee that applauds the demo and files the design is how the breach gets scheduled. The refusal is the same refusal as keeping the agent inside the running user's sharing. The centre is where that refusal has to be usable against a senior ask, in the week of the workshop, not in a quarterly review after the permission set has shipped.
Capacity is part of the design. If you do not have architects on the payroll to sit in intake, pair the centre with managed capacity that is actually present on the days requests arrive. A rota of visitors will reproduce the monthly slide. Name the days. If intake is unanswered for a week, people will build, and they will be rational to do it. A centre that is present on Tuesdays and dark the rest of the week has told the organisation which days the standard applies.
Check the licence before the yes
Data 360 help is a useful test of whether intake is awake: "Some Data 360 features are offered as add-on licenses, and others have usage limitations, though many limits can be adjusted to meet your business needs." A centre that approves work without asking which licence it needs, and which limit it will meet, is approving a failure. The adjustment, where one is possible, is a commercial conversation with a date. It is not a blank you fill by assuming the feature is included.
The same three questions apply to platform features that are not Data 360. What did we buy. What runs out. Who is accountable when it runs out. Editions differ. Allowances differ. This page will not print a cap. The intake form has a line for the figure someone looked up, the date they looked it up, and the name of the person who will notice if the use grows. A yes without those three lines is a yes to a surprise. Put the lines in front of the solution sketch, not in an appendix after the build has started.
A pilot that is "only in a sandbox" still answers the questions. Sandbox licences and production licences are not the same surprise, and a design that only fits a limit you have not bought will be the design people want moved. Say so before they fall in love with it.
What it is not
It is not the only team allowed to click. Local admins still configure local layouts, truly local picklist values, and report folders, inside the written standard. The standard says which of those need no design, so the centre is not a bottleneck for a column move. It is not a quarterly steering group that discovers the org in an appendix. Steering can set priority. It cannot see the request on Thursday. It is not a path that only says yes to executives. The refusal has to work when the request is senior. The standard is the reason, so the no is about the rule, and the same rule applies to a small ask from a quiet team. Selective enforcement is how the standard becomes optional.
Answer intake in days. A monthly batch is an invitation to build anyway and apologise. Once a quarter, read the refusals, not as a ceremony but as a test of authority. If every no was ignored, or quietly built under another ticket, the centre has no authority. That is the problem to fix before you add another charter page. A charter that cannot point at a refusal someone obeyed is a name. The queue with the same name will be routed around, and production will change anyway.
| The centre does | A pass looks like | A queue looks like |
|---|---|---|
| Publish standards where builders look | A builder can find the rule before they build | The rule is in last year's slide |
| One intake | Process, object, and the owner after go-live | A product name and a demo date |
| A recorded no | The standard cited, and what would change the answer | A verbal hesitation, then the build |
| Architects in the room | The request is read before it is a flow | A monthly visit to prepared slides |
| Licence and limit before yes | Figure, date looked up, person who watches it | A yes, and a surprise in week two |
A duplicate field is the request the centre sees most often, and it is the one a queue will build. Marketing asks for a stage. Sales already has a stage. Intake that only asks for a product name will create a second field. Intake that asks which object and which process will find the existing field and the sentence that already defines it. The recorded no cites that sentence. The asker can propose a change to the sentence. They do not get a second field because the first was inconvenient to share.
The same pattern arrives as a flow. A workshop wants a small automation on the opportunity save. The object already has an owner and an order of work. The centre does not design the flow in the intake meeting. It sends the request to that owner with the band written on it: before save, after save, or not on the save at all. If the owner merges it, the yes is theirs. If they refuse, the centre records the refusal and does not reopen it because a sponsor asked twice. Reopening without a new fact is how the standard becomes a negotiation.
Read the refusals for a pattern. Five nos that cite the same rule mean the rule is doing the work. Five nos that cite five different moods mean you do not have a standard yet. Rewrite the rule until the nos look alike. And time the intake. If the usual answer takes weeks, publish that beside the charter. A centre that answers in three weeks will be routed around by anyone with a date. The fix is someone present on the days requests arrive, and a form short enough that people will use it.
Cheap, this month: one front door, a form that asks for the process and the object, standards moved to where builders already work, and a refusal written down with the rule it cites.
Expensive, after a year of apologies: an org of duplicate fields, flows nobody owns, and a permission set opened for a demo that is now how the agent runs. You will not sort that with a new charter. You sort it by making the next no stick, in days, against a request someone senior wants. If that no is ignored, fix the authority before you fix the template. The template is not the problem.



