Salesforce Center of Excellence: format and cadence

A Salesforce Center of Excellence (CoE) is the body on the client side that sets standards and aligns upcoming changes across all teams and partners. For a manufacturer with several implementation partners, two meetings are enough to start: a technical call every two weeks where streams present changes to shared objects with lead time, and a monthly meeting for roadmap and priorities. The client chairs it, not a partner. In my largest programme, regular CoE calls made new edge cases almost disappear, because topics came up before they turned into conflicts.

What is a Salesforce Center of Excellence?

In the Trailhead module Salesforce Governance with a Center of Excellence1, Salesforce describes the CoE as a team of experts from across the organisation that acts as the steering committee and knowledge hub for all Salesforce initiatives. It has three jobs there:

• Vision: a roadmap of where the platform is going, prioritised by value.
• Standards: rules for how work is done on the platform, from processes and data quality to development rules.
• Enablement: training, communication and support for users and teams.

In manufacturing companies with several partners, the second point is the most urgent in my experience. A roadmap usually exists already in some steering committee. What is missing is the place where teams settle, bindingly, who changes what in the org. Without that place you get what Salesforce calls governance debt2: technical debt, inconsistent data and users who build spreadsheets on the side.

Why does the CoE belong on the client side?

A partner can moderate a CoE, and some sell that as a service. The problem: whoever sets the rules decides how everyone else builds. If five partners work on one org and one of them runs the CoE, it decides what its competitors are allowed to do. That is the same reason I insist on client ownership for the object ownership matrix and for repository and pipeline.

Partners still sit at the table. Their leads present changes, bring edge cases from the project and push back when a standard does not work in practice. The chair, the decision and the documentation stay with the client, through a CoE lead and an architect.

Which format does a CoE need at the start?

Trailhead recommends a weekly schedule for operational and technical topics and a monthly one for strategy and roadmap3. In my programme the technical call ran every two weeks for 60 minutes, and that was enough, because topics were submitted in advance and the agenda went out before the meeting. Weekly only pays off when the list of submitted topics is permanently longer than an hour. You do not need more meetings at the start.

	Technical CoE call	Roadmap meeting
Cadence	every two weeks, 60 minutes	monthly
Chair	client-side architect	CoE lead
Attendees	only the technical leads of all streams and partners	sponsor, CoE lead, business units, architect
Content	upcoming changes to shared objects, edge cases from reviews, new or changed standards	priorities, roadmap, budget, new partners
Outcome	a decision, an updated standard or matrix	a prioritised backlog for the coming months

The roadmap meeting is also the place for budget questions that cut across units. One example is the Agentforce allowance I describe in Digital Wallet: Agentforce cost control for plants: someone in the CoE has to watch the pool and run the chargeback to plants and subsidiaries.

The technical call always follows the same agenda

The technical call is the part that makes the difference. To keep it from turning into a status meeting, streams submit their topics in advance and the agenda goes out to all attendees before the meeting. That way the owning stream can prepare instead of deciding on the spot. The agenda always follows the same order:

1. Upcoming changes to shared objects. A stream presents what it wants to change on Account, Asset or another shared object, before it builds. The owning stream according to the matrix says whether it fits and where the change belongs.
2. Edge cases from reviews. Anything that came up in pull request reviews and is not covered by a standard comes here.
3. Record decisions. Every decision goes where the standards live, not into one partner’s meeting minutes.

Status reports do not belong in this call. Whoever wants to report what their team finished in the sprint does that in the sprint review. Otherwise 15 people sit together for an hour and the one change to Account that the call was meant for gets five minutes at the end.

Next to the agenda I keep a backlog of CoE topics that are not urgent, such as naming conventions for new object types or a rule that keeps coming up in reviews. When few topics come in for a meeting, we take one from the backlog. That way no meeting gets cancelled and the cadence stays stable.

It also matters who decides. The question belongs to the stream that owns the object. If two streams cannot agree, the client-side architect decides. A CoE that settles every question by vote becomes slow and political.

In my programme with eight streams the edge cases almost disappeared

The largest programme I steered had more than 30 developers in eight streams, delivered by five implementation partners and internal teams. At the start nobody had defined which team owned which objects and metadata. Changes overwrote each other.

First we sent every change through a pull request with review and wrote standards from what the reviews showed, including the object ownership matrix. The CoE came in as the second building block, as the place for everything the standards did not cover yet.

The handover is where you see whether the CoE holds. If it depends on an external person, it ends with that person’s contract. That is why an internal owner belongs in it from day one, first sitting in on the calls and then running them.

Centralised, federated or hybrid: which model fits?

Trailhead distinguishes three models. In the centralised model the CoE can veto poor technical designs instead of only making recommendations. In the federated model individual units run their own implementation and the CoE advises. In the hybrid model the CoE sets standards centrally and the units enforce them themselves.

For several partners on one shared org I would start centralised. When five partners build on the same objects, someone has to be able to say no, and the review enforces that no technically.

If a group runs several orgs, for example one per subsidiary, the hybrid model fits better. The CoE then sets the shared rules and each org enforces them with its own team.

Name a sponsor and a CoE lead

A CoE does not have to be a new department. This is the order I recommend:

1. 01

   Assign ownership

   client

   Name a sponsor in management and a CoE lead. Without backing from the top, rules stay recommendations.

2. 02

   Write the first standards

   architect

   Development standards and an object ownership matrix in a first version that covers around 80 percent of cases.

3. 03

   Start the technical call

   architect and technical leads

   Every two weeks for 60 minutes, topics submitted in advance, agenda sent beforehand, backlog of reserve topics.

4. 04

   Add the monthly roadmap meeting

   CoE lead and business units

   Priorities, budget and new partners, once the technical call runs.

5. 05

   Hand over

   internal owner

   An internal colleague takes over the calls and maintains the standards.

How to anchor new rules in daily work is described under Salesforce change management consulting, and how the call keeps standards in place with partners in Reinforcement: making standards stick with partners. The overall frame for several partners is under partner governance.

Sources3

1. 1Salesforce Governance with a Center of Excellence (opens in a new tab)trailhead.salesforce.com
2. 2governance debt (opens in a new tab)trailhead.salesforce.com
3. 3weekly schedule for operational and technical topics and a monthly one for strategy and roadmap (opens in a new tab)trailhead.salesforce.com