A Salesforce Center of Excellence built as a control structure turns into a queue that business units learn to avoid. It earns its place when going through it is faster than going around it. That depends on two decisions taken before the intake form grows: what the CoE reviews, and what it gives back to project teams.
How a CoE becomes a queue
The weak playbook is familiar. Centralise governance, create an intake form, set up a review board, publish standards, and never measure whether teams can use them. The board meets once a quarter, approves what is already deployed, and delivery goes around it.
Three design errors produce this. The CoE is built to prevent bad decisions rather than speed up good ones, so teams under pressure have every reason to avoid it. It can publish standards but cannot stop a release, so the real rules are set by the pipeline and the integrator’s release calendar. And its core members keep objectives tied to one business unit, so that unit’s requests quietly set the CoE’s priorities. A CoE stays neutral only if the people who take its key decisions are measured on platform stability and standards, and not on one unit’s targets.
Three layers, and the one most CoEs build first
| Layer | Owns | Produces |
|---|---|---|
| Platform | Release management, environment strategy, security baseline, data standards, the technical debt register | Constraints. Small, senior, allowed to say no. |
| Delivery | Solution design patterns, Flow and agent governance, integration contracts | Reusable assets and reference designs that make project teams faster |
| Demand | Intake, prioritisation, business cases, capacity, vendor management, escalation when projects conflict | Decisions on what gets done first |
The usual mistake is to build the demand layer first, because it is the most visible to management. The result is process without capability. Business units feel the friction of intake, get no reusable pattern back, and conclude that going around the CoE is worth the risk. Most of the CoE’s effort belongs in the delivery layer.
Size the model to the org
- One Sales Cloud and Service Cloud org, one internal admin team. A CoE is overkill. A decision log, a release calendar and a named design authority who reviews significant changes are enough.
- Several clouds, several business units, a mix of internal and external delivery. A federated model. A central platform team sets standards and owns the org baseline; each business unit has an embedded Salesforce lead accountable to both the unit and the central team. Team size and review cadence follow the real change volume and risk.
- Many clouds, many teams or vendors. A formal operating model with service levels, decision rights that can be enforced, and a technical debt register that feeds budget planning (the technical debt note covers how to keep it).
Fully central models create bottlenecks. Fully decentralised ones produce sprawl and inconsistent data. Choose on decision delay, shared-platform risk and local accountability, not on a default.
What the review board reviews
I piloted the TotalEnergies Salesforce Center of Excellence from 2019 to 2021, when TotalEnergies was a Cognizant client, an account of about €1M a year. Salesforce was used in several parts of the group and exchanged data with other systems, so each change had to be checked against those flows before release. A CoE in that position cannot review every change with the same depth. Its review scope has to be decided explicitly, or the queue decides it.
A board that reviews everything reviews nothing well. Four categories, and nothing else:
- Data model changes that affect more than one cloud or add relationships between shared objects.
- Integration contracts that add an external dependency or change an existing API contract.
- Agent and AI configurations going to production: new topics, actions or prompt templates.
- Security and sharing changes: org-wide defaults, profile assignments at scale, data residency. Reversible on paper, rarely in practice.
Everything else goes through standard release management. Frequent low-risk changes get a light approval track, owned by the business unit and audited afterwards. Two rules make the board’s decisions stick. A change without an approval reference does not enter the release pipeline, so approval and deployment cannot drift apart. And when an integrator does the build, passing the CoE’s standards and gates is written into the contract’s acceptance terms; otherwise the standards stay a line on a slide.
Assets and measures that keep the CoE funded
The CoE earns its budget through the asset library more than through approvals. A minimum library holds approved Flow patterns for common cases (case escalation, lead routing, approval chains), integration patterns for the org’s usual external systems, approved prompt templates, and a checklist per cloud. The test for an asset is practical: if it takes longer to understand and adapt than to rebuild, nobody will use it.
Maintenance is the harder part. An asset that is not updated when a Salesforce release changes the platform starts to mislead. Each asset category needs a named owner who reviews it at every release and flags what is being deprecated.
Ticket volume and review cycle time describe the process. They say nothing about its value. Three comparisons, reviewed each quarter with the executive sponsor, show whether the CoE is worth its cost: the share of projects that use CoE assets instead of building from scratch, the defect rate of reviewed projects against those that bypassed review, and time to production inside the CoE against outside it. If CoE projects are slower, the overhead exceeds the benefit, and the model has to change.
What to check
- Can a team lead name the org’s non-negotiable rules without opening a document?
- Can the CoE stop a release, or only publish standards?
- Is the review board’s scope written down, and does it leave single-unit changes out?
- Does every asset have a named owner who reviews it at each release?
- Does the sponsor see reuse, defect and lead-time comparisons every quarter?