Building a Salesforce Center of Excellence From Scratch

Short answer: a Salesforce center of excellence is a small team with real decision rights over the platform, not a committee that meets monthly to review other people's work. At mid-size you can build one with four part-time people and three artefacts. Governance fails when it is designed to prevent decisions rather than to make them quickly.

What is a Salesforce center of excellence, actually?

Strip away the enterprise vocabulary and a CoE is three things:

• A named owner of the platform. One person who is accountable for whether Salesforce serves the business, not five who are consulted.
• A short list of decisions that only they make. Data model, integrations, security model, release process.
• A set of reusable assets so the next project starts at 60% rather than zero.

Everything else people put in a CoE charter is either a meeting or a document, and neither changes what ships.

Do you need one at mid-size?

Most CoE advice is written for orgs with thousands of users. You do not need the enterprise version, but you do need something the moment these signals appear:

• Two departments have built overlapping objects that mean nearly the same thing.
• Nobody can say what a change to Account will break.
• Every project rebuilds the same integration or approval pattern from scratch.
• Releases wait on one person's calendar.
• The backlog is arbitrated by whoever escalates loudest.

Two or three of those and you already have a governance problem. You just have not named it yet.

Who is on the minimum viable CoE?

Four roles, and at mid-size most of them are part of somebody's existing job. Resist the urge to staff a department.

• Platform owner (20-40%). Usually a product or ops leader. Owns the roadmap and says no. This is the role that cannot be shared.
• Lead architect or senior admin (50%). Owns the data model, the security model and technical standards. Reviews changes that cross object boundaries.
• Release owner (20%). Owns the pipeline, environments and the release calendar. Often the same person as the architect early on, but the responsibility should be written down separately.
• Business representative per major function (10% each). Sales, service, finance. They bring demand and take decisions back to their teams. They are not there to approve technical work.

Four people, roughly 1.2 full-time equivalents. That is the whole thing. A CoE that needs six new hires before it can operate will be cancelled in the next budget round.

What decisions does the CoE own, and what does it not?

This is the part teams skip, and it is the only part that determines whether the CoE survives. Write two explicit lists.

The CoE decides: changes to shared objects and the data model, new integrations and the systems of record behind them, the security and sharing model, the release process and its gates, which capabilities get built as reusable components, and what goes on the roadmap.

The CoE does not decide: report and dashboard layouts, page layout tweaks inside one team's own objects, field label wording, or which of two equally valid implementations a developer picks. Those belong to the people doing the work.

The second list matters more than the first. A body that reviews everything becomes a queue, and a queue gets routed around. Within a couple of quarters people will be building in their own sandboxes and asking forgiveness, which is exactly the state you set the CoE up to end.

Why committees fail and small teams do not

A committee optimises for consensus, which means its default answer is delay. A team optimises for throughput, which means its default answer is a decision, sometimes a wrong one. On a platform where a wrong field can be renamed next sprint but a stalled roadmap costs a year, the team wins that trade every time.

Three rules keep it a team:

1. Decisions have a deadline. Anything not decided within one week defaults to the architect's recommendation. Silence is consent.
2. Meet weekly for 45 minutes, not monthly for two hours. Short cadence means small decisions, which are the reversible kind.
3. Publish decisions, not minutes. One line per decision, with the reason and the date. That log becomes the standards document nobody had time to write.

What should it produce in the first 90 days?

1. Days 1-30: the decision-rights document above, and an honest inventory of what exists. Objects, integrations, automation, technical debt, who owns what.
2. Days 31-60: the release process. One pipeline, one set of environments, approval gates by environment, and no direct changes in production.
3. Days 61-90: the first two reusable components. Pick the patterns you have already built twice, package them properly, and use them on the next project.

That third item is what turns a CoE from an overhead into an asset. Building products taught us this the hard way: at Tekunda we work as a Salesforce SI, ISV and PDO, and the packaging rigor from the product side is exactly what lets a delivery team bring new work live in weeks rather than months. A CoE that produces reusable parts pays for itself. A CoE that produces policy documents gets cut.

FAQ

How big should a Salesforce CoE be?

At mid-size, four roles totalling roughly one to one and a half full-time equivalents. Add people only when a specific decision keeps waiting on capacity.

Should the CoE sit in IT or in the business?

Neither exclusively. The platform owner should come from the business and the architect from IT, reporting jointly. A CoE owned entirely by IT drifts from demand, one owned entirely by the business drifts from architecture.

What is the difference between a CoE and a governance board?

A governance board reviews decisions made elsewhere. A CoE makes them and is accountable for the outcome. If your CoE only reviews, you built a board.

How do you know the CoE is working?

Time from request to production falls, the number of changes made outside the release process approaches zero, and each project reuses more than it rebuilds.