- The three layers of Salesforce governance — platform, programme, and operational — and what each owns
- How to use a RACI matrix to assign clear ownership to every type of Salesforce decision
- How to design escalation paths that resolve conflicts without bottlenecking delivery
- The most common governance failures and the structural causes behind them
- What good governance looks like in practice — meetings, cadences, and decision records
Why Governance Fails
Most Salesforce governance frameworks fail for one of three reasons. First, they are too heavy — every decision requires a committee, every change requires a document, and teams work around governance rather than through it because it takes longer to get permission than to ask forgiveness. Second, they are too light — governance exists on paper but not in practice, with no real decision authority, no consequences for bypassing process, and no enforcement mechanism. Third, they are designed for the wrong phase — governance structures that work during implementation break down post-go-live when the nature of decisions changes from "what are we building" to "what should we change."
Effective governance is proportionate to decision risk, appropriate to the phase of the programme, and backed by genuine authority. It does not need to be bureaucratic — but it needs to be real.
Platform governance: owned by a senior body (Platform Board or IT Leadership), sets strategic direction, approves major architectural decisions, manages investment. Programme governance: owned by the programme team, manages delivery, change control, and risk within the programme. Operational governance: owned by the CoE, manages day-to-day change requests, release management, and incident resolution. Each layer owns distinct decisions; escalation paths connect them.
Platform Governance: The Strategic Layer
Platform governance operates at the level of Salesforce strategy, not individual changes. The Platform Governance Board (or equivalent body) meets quarterly — more frequently during programme phases — and owns the following decisions:
- Salesforce strategic roadmap: what capabilities will be built, in what sequence, over the 3-5 year horizon
- Major architectural decisions: org strategy (single vs multi), cloud additions, Data Cloud or Agentforce adoption
- Investment envelope: annual Salesforce budget across licences, implementation, CoE operations, and enhancements
- Build vs buy policy: standards for when to use AppExchange vs custom development
- Data governance principles: data quality standards, master data management decisions, data residency
Platform governance should have senior business representation — not just IT. If the only people in platform governance meetings are IT staff, the platform will be optimised for IT concerns rather than business outcomes. A CFO, Chief Revenue Officer, or Head of Operations as a standing member of the Platform Board gives the governance layer the authority it needs to make decisions that affect business strategy.
Programme Governance: The Delivery Layer
Programme governance manages the ongoing delivery of Salesforce changes — whether in a formal implementation programme or as post-go-live enhancement delivery. It owns:
Change control. Formal assessment of proposed changes against scope, architecture standards, and resource capacity. The programme governance layer decides whether a change is in scope, out of scope, or requires escalation to the platform layer.
Risk management. Identification, assessment, and mitigation of delivery risks. Programme governance has authority to adjust timelines, scope, or approach to manage risk — within the parameters set by platform governance.
Dependency management. Cross-workstream dependencies that would otherwise block progress are escalated to programme governance for resolution.
Acceptance criteria. What "done" means for each deliverable. Programme governance owns the quality gates and acceptance decisions.
Operational Governance: The Running Layer
Operational governance is the day-to-day governance of the live Salesforce platform. Owned by the CoE, it covers:
Change request management. Receiving, triaging, prioritising, and delivering change requests from business stakeholders. The operational governance cadence is typically a weekly or bi-weekly change control board that reviews the request queue and authorises releases.
Release management. Planning and managing the Salesforce release calendar — both Salesforce's own tri-annual releases and the organisation's own release cadence for configuration and custom development.
Incident management. Defining and managing the response process for platform incidents — from minor bugs to P1 outages. Who declares an incident, who leads the response, who communicates to the business.
User access and security. Provisioning and deprovisioning users, managing permission sets and profiles, conducting periodic access reviews.
Decision Authority and RACI
The most common governance failure is unclear decision authority — multiple people think they own a decision, or nobody thinks they own it. A RACI matrix resolves this by assigning each decision type to specific roles:
R (Responsible): Does the work to make the decision happen.
A (Accountable): Owns the outcome — signs off and takes responsibility. Only one person per decision.
C (Consulted): Input is required before the decision is made.
I (Informed): Notified after the decision is made.
Key Salesforce decisions and typical RACI assignments in an enterprise context include: new cloud adoption (A: CTO, R: CoE Lead, C: Platform Board), major custom development (A: CoE Architect, R: Developer Lead, C: Business Sponsor), routine configuration change (A: Salesforce Admin, R: Salesforce Admin, I: Business Owner), user access change (A: Salesforce Admin, R: Salesforce Admin, I: Line Manager).
A governance meeting that does not make decisions is not governance — it is a status update session with a governance name. Every governance meeting should have a decision register: what decisions were made, by whom, and what the rationale was. Governance that produces meeting minutes but no decision records will eventually fail to provide the accountability it was designed to create.
Escalation Paths and Conflict Resolution
Every governance framework needs defined escalation paths — the route a decision takes when it cannot be resolved at the current level. Without clear escalation paths, decisions stall at the level where the conflict first surfaces.
The escalation path for Salesforce typically flows: Operational (CoE) → Programme → Platform → CTO/IT Leadership. Each escalation should come with a recommendation from the escalating level, a defined timeline for resolution (no more than 5 business days at each level), and a decision owner at the receiving level.
Cross-functional conflicts — where a Salesforce change affects multiple business units with conflicting requirements — are the most common escalation. The Platform Board or its delegate must be empowered to make the call, even when one business unit is unhappy with the outcome. Governance that cannot produce decisions that some stakeholders disagree with is not real governance.
Document your governance framework in a one-page Governance Charter: the three layers, who owns each, what they decide, how they escalate, and how often they meet. Circulate it to all stakeholders. When conflicts arise — and they will — the Charter gives you a documented framework to reference rather than having to negotiate governance on the fly. A governance framework that exists only in people's heads is not a governance framework.
Key Takeaways
- Governance fails when it is too heavy (bureaucratic), too light (no real authority), or designed for the wrong phase of the programme
- Three governance layers are needed: platform (strategic), programme (delivery), and operational (day-to-day) — each with distinct ownership and decision authority
- Platform governance needs senior business representation — IT-only governance optimises for IT concerns rather than business outcomes
- RACI matrices resolve unclear decision authority — one accountable owner per decision type, consistently applied
- Escalation paths must be defined explicitly: who escalates to whom, within what timeframe, with what expectation of resolution
- Document the governance framework in a one-page Charter that all stakeholders can reference when conflicts arise
Checkpoint: Test Your Understanding
1. A Salesforce change request affects both the Sales and Service teams, who have conflicting requirements. The CoE cannot determine which team's requirement takes priority. What should happen?
2. The Platform Governance Board meets monthly and has five IT representatives and one business stakeholder (a junior business analyst). What is the primary structural problem?
3. In a RACI matrix for Salesforce governance, what is the correct interpretation of "A" (Accountable)?
Discussion & Feedback