- What a Salesforce CoE does and why organisations that skip it pay the price post-implementation
- The two CoE operating models — centralised and federated — and when each is appropriate
- The five core roles every Salesforce CoE needs, and the minimum viable staffing model
- How to scope and fund the CoE in the original business case, not as an afterthought
- The governance responsibilities of the CoE and how to avoid becoming a bottleneck
What Happens Without a CoE
The Salesforce implementation goes live. The partner team reduces to a hypercare support arrangement, then disengages. The programme team disperses back to their business-as-usual roles. A single Salesforce Administrator — usually the most technical person who was involved in the programme — is left holding the keys to a complex, business-critical platform.
Without a CoE, what follows is predictable. The development backlog accumulates because there is no team to clear it. Changes are made inconsistently because there is no architectural oversight. The platform drifts from best practice as each point solution is implemented without regard for the whole. Technical debt accumulates. Release management becomes informal. Security and compliance gaps emerge. And the single admin, increasingly overwhelmed, eventually leaves — taking institutional knowledge with them.
The Centre of Excellence is the structural solution to this problem. It is the permanent internal capability that owns the Salesforce platform after the implementation partner exits.
A Salesforce CoE has four functions: (1) Platform operations — keeping the org healthy, compliant, and performant. (2) Delivery — building the ongoing development backlog. (3) Governance — ensuring architectural consistency and managing change requests. (4) Enablement — growing the organisation's Salesforce capability and supporting users. All four are necessary; many CoEs focus only on the first two and neglect governance and enablement.
Centralised vs Federated CoE
The first design decision for a CoE is whether it is centralised or federated.
Centralised CoE. A single team owns Salesforce across the entire organisation. All requests, all development, all governance flows through this team. The benefits are consistency, quality control, and efficient use of specialist skills. The risks are that the central team becomes a bottleneck — business units experience slow delivery and work around the governance rather than through it. Centralised CoEs work well when the Salesforce footprint is primarily in one or two business units and the volume of change requests is manageable by a single team.
Federated CoE. Each major business unit has its own Salesforce capability (admins, developers), coordinated by a central platform team that owns architecture standards, shared components, and cross-org governance. Business units have speed and autonomy; the central team ensures consistency. Federated CoEs work well for large, multi-cloud, multi-division Salesforce deployments where a centralised team cannot keep pace with demand. The risk is inconsistency if the coordination function is weak.
The Five Core Roles
A minimum viable Salesforce CoE requires five capabilities, delivered by dedicated roles:
Salesforce Administrator. Day-to-day platform operations: user management, configuration, report and dashboard maintenance, first-line support, release management for Salesforce tri-annual releases. The Admin is the operational heartbeat of the CoE. For a single-cloud org with under 500 users, one Admin may be sufficient. Complex multi-cloud orgs typically need 2-4 Admins.
Salesforce Developer. Custom Apex, LWC, integration code, complex automation. Not all orgs need a full-time developer — low-customisation orgs can meet developer needs with a fractional arrangement or partner retainer. But any org with a meaningful custom development estate needs dedicated internal developer capability.
Solution Architect. Architectural governance, technical standards, integration design, review of significant changes. The Architect ensures that the org remains coherent and maintainable as it evolves. Without an Architect function, technical decisions accumulate inconsistently and the org degrades.
Business Analyst / Product Owner. The business-facing role. Translates business requirements into Salesforce work items, manages the development backlog, coordinates user acceptance, and ensures that what the CoE builds actually meets business needs. The BA/PO is the bridge between the CoE and its stakeholders.
CoE Lead. Senior leadership accountability for the Salesforce platform. Reports to the CTO or IT Director, owns the platform roadmap, manages the CoE budget, and represents Salesforce interests in business strategy discussions. The CoE Lead is the person who ensures the platform receives the investment it needs and that the CoE's value is understood at senior level.
Funding the CoE in the Business Case
The most common CoE failure mode is not structural — it is financial. The implementation gets funded. The CoE does not, or gets funded at a fraction of what it needs. The result is a well-built platform maintained by an understaffed team that cannot keep pace with demand.
The CoE should be funded in the original implementation business case as a permanent operating cost, not as an afterthought approved separately. A useful funding formula: the CoE annual operating cost (salaries, tools, training) should be approximately 20-30% of the implementation cost, per year, indefinitely. This accounts for administration, development, and governance capacity appropriate to the org's complexity.
For a £2M Salesforce implementation, budget £400,000-600,000 per year for the CoE. This sounds significant — it is. It is also significantly less than the cost of re-engaging the implementation partner to fix problems that accumulate from an under-resourced CoE.
Governance Without Becoming a Bottleneck
CoEs that are perceived as bottlenecks — slow, bureaucratic, unhelpful — lose influence. Business units work around them, make independent decisions, and the CoE becomes irrelevant to the most important platform decisions. Avoiding this requires deliberate design of the governance model.
Tiered change management. Not all changes need the same governance overhead. Routine configuration changes (new user, new picklist value, new report) should be processed quickly, with light-touch approval. Medium complexity changes (new flow, new integration point) need architectural review. High complexity changes (new data model, new custom development, new AppExchange package) need formal CoE review and architectural sign-off. Applying heavyweight governance to routine changes destroys velocity.
Service level commitments. The CoE should publish and meet service level commitments: routine changes within 2 business days, medium changes within 2 weeks, architectural reviews within 4 weeks. Without SLAs, "the CoE is slow" becomes an unfalsifiable complaint. With them, performance is measurable and manageable.
A CoE's influence comes from the trust of its stakeholders. It builds trust by delivering on its commitments, saying no with a reason and an alternative, and demonstrating that its governance exists to protect the platform — not to protect the CoE's territory. CoEs that are seen as business partners rather than IT gatekeepers consistently receive better stakeholder engagement and more strategic investment.
Key Takeaways
- Without a CoE, post-implementation platforms accumulate technical debt, inconsistent architecture, and operational fragility — the partner exit is the trigger, not the cause
- A Salesforce CoE has four functions: platform operations, delivery, governance, and enablement — all four are necessary
- Centralised CoEs deliver consistency; federated CoEs deliver speed and autonomy — choose based on organisation size, platform complexity, and change volume
- The five core roles are Admin, Developer, Architect, BA/Product Owner, and CoE Lead — all five are needed; the minimum viable staffing depends on org complexity
- Budget the CoE at 20-30% of implementation cost per year — underfunded CoEs produce the conditions for expensive platform failure
- Tiered change management with SLAs prevents the CoE from becoming a bottleneck — govern proportionately, not uniformly
Checkpoint: Test Your Understanding
1. A large financial services organisation with 3,000 Salesforce users across four business divisions is designing its post-implementation operating model. What CoE structure is most appropriate?
2. The CoE is perceived by business stakeholders as slow and unhelpful. Every change request — from adding a new user to major new automation — goes through the same 4-week review process. What is the root cause and fix?
3. A £3M Salesforce implementation business case shows zero ongoing CoE investment post-go-live. What is the most significant risk this creates?
Discussion & Feedback