Technical Leadership
Your Salesforce CoE should reduce waiting—not create it
Governance is a decision system
A Salesforce Centre of Excellence is often introduced after an org becomes difficult to change. Leaders create a committee, require architecture review and add approval stages. The intention is sensible: stop duplicated fields, fragile automation and inconsistent integrations. The failure is treating attendance and sign-off as the product. Teams wait longer, urgent work finds side doors and the org still accumulates debt.
Salesforce describes a CoE as a structure connecting business and technology leadership, establishing standards, building expertise and solving difficult implementation problems. That purpose is broader than control. The practical test is whether people reach sound, traceable decisions faster. If governance adds delay without improving the quality, consistency or reversibility of decisions, it is not protecting delivery; it is becoming another delivery risk.
Centralise only the decisions that must be shared
The CoE should own decisions whose consequences cross product or business boundaries: enterprise data definitions, identity patterns, integration standards, security baselines, shared automation, platform limits and the retirement of widely used capabilities. These choices create coordination value because one team's local optimisation can impose cost or risk on many others.
Product-level choices should remain with accountable delivery teams when they stay inside approved boundaries. A team should not need an enterprise forum to adjust a page layout, refine copy or change an isolated report. Publish decision rights by category, name the accountable role and specify when escalation is required. Ambiguity creates more delay than a strict rule because every request begins with discovering who is allowed to decide.
Route work by risk, not by visibility
Large presentations do not necessarily describe high-risk changes. A small permission change can expose sensitive records; a substantial component refactor may preserve every contract. Classify requests using their effect on data ownership, security, integrations, shared metadata, transaction volume, AI behaviour and customer-facing journeys. The review path should follow consequence, not who requested the work or how many components appear in the manifest.
Create an explicit fast lane for low-risk work that meets published standards, a focused review for changes that cross one controlled boundary and a full design decision for high-impact changes. Record why the route was chosen. This preserves attention for the work that needs judgment while giving teams confidence that routine change can move without waiting for the next committee calendar slot.
Replace repeated advice with paved roads
If architects repeat the same guidance in every review, the organisation has not converted knowledge into capability. Turn stable decisions into reusable patterns: a standard integration envelope, permission-set model, Flow error contract, logging approach, component data-access pattern and release checklist. Provide a working example, ownership, supported use cases and the conditions that require an exception.
A paved road must be easier than inventing a private alternative. Keep reference implementations small, testable and current. Offer starter templates and automated checks where they remove interpretation. Retire patterns that no longer fit the platform. The CoE creates leverage when one hard decision improves many future deliveries; it creates dependency when every team must ask the same expert to repeat that decision manually.
Keep decisions short and durable
Governance needs memory, but it does not need a thirty-page document for every choice. Use a concise decision record containing the problem, constraints, options considered, selected approach, trade-offs, owner, date and conditions that would trigger review. Link the record to the business outcome and affected systems. The purpose is to preserve reasoning, not to reconstruct every meeting.
This record prevents settled questions from reopening whenever team membership changes. It also makes technical debt deliberate. A team may accept a short-term workaround, but the decision should state the cost, expiry condition and accountable owner. Undocumented compromise turns into permanent architecture because future teams see only the implementation and assume it was designed as the preferred state.
Make exceptions governed and reversible
Standards cannot predict every legitimate constraint. A credible CoE therefore provides an exception path with evidence requirements and a response target. The requester should explain the business need, affected controls, alternatives rejected, duration, monitoring and recovery plan. The reviewer should approve, reject or time-box the deviation—not leave it in an indefinite state labelled under discussion.
Give every temporary exception an expiry date and review owner. Track whether it is removed, renewed with new evidence or converted into an updated standard. Patterns sometimes need to evolve because several teams encounter the same limitation. An exception register is therefore not only a risk list; it is a source of product feedback showing where enterprise guardrails no longer match the work teams are trying to deliver.
Run governance at more than one cadence
Salesforce's August 2026 guidance for CoEs recommends continuous transparency, a frequent operational review and a separate strategic rhythm. The underlying principle is useful beyond AI: different decisions expire at different speeds. Delivery conflicts and production risks need rapid resolution, while portfolio priorities, technical-debt investment and operating-model changes need broader evidence and senior authority.
Use asynchronous records for routine visibility, a short weekly forum for blocked or cross-team delivery decisions and a monthly or quarterly steering review for investment and policy. Do not make the strategic group relitigate component design. Do not leave enterprise conflicts to project stand-ups. Each forum needs a defined decision scope, prepared inputs, an accountable chair and published outcomes.
Measure flow and outcomes, not meeting volume
Track how long each risk class waits for a decision, how often reviews require rework, how many production defects trace to ignored standards and how many teams adopt supported patterns. Monitor the age and recurrence of exceptions. These signals show whether the operating model is creating clarity or simply moving uncertainty into a queue.
Connect governance to business results as well. For significant changes, record the adoption, service, revenue, risk or efficiency measure that justified the investment, then review the evidence after release. Salesforce's current CoE guidance emphasises defining success measures before changes are approved. Without that loop, the CoE can become excellent at governing delivery activity while remaining unable to say whether the platform is producing value.
The JSBC Labs view
A strong Salesforce CoE is a distributed decision system with a small authoritative centre. Centralise enterprise boundaries, delegate product choices, route work by risk, encode repeated advice into paved roads and keep exceptions visible and temporary. Use different cadences for operational and strategic decisions, then measure both decision flow and the business outcomes that follow.
The goal is not to make every decision centrally consistent. It is to make important decisions consistent, ordinary decisions local and every decision accountable. When teams know the guardrails, evidence and escalation route before they begin, governance stops feeling like a gate. It becomes the infrastructure that lets a growing Salesforce estate change quickly without losing coherence.