An enterprise Salesforce org can run for years on imperfect code. It stops moving when nobody can say who decides. A RACI chart and a change board that meets once a quarter do not settle that. Governance has to state where authority sits, how each change is classified, and who breaks the tie when two owners disagree.
When that is missing, the damage is drift rather than a single incident: shadow configuration, undocumented integrations, business units overwriting each other’s metadata, and a platform that gets harder to change with every release.
Decision rights at three levels
Authority has to be explicit at three levels.
- Platform level: org strategy, release cadence, standards, the security and sharing model. One small group, with a named person who can say no.
- Domain level: the owner of one cloud, or of one business unit’s configuration.
- Change level: who approves each category of change, and within what delay.
Collapse the three into one approval queue and you get a bottleneck that teams learn to route around. That is how shadow development starts. A governance model that exists only to refuse gets bypassed. One that makes the safe path the short path gets followed.
The escalation path matters as much as the levels. When two domain owners disagree about a shared object, the platform level decides, and the delay for that decision is written down.
On the L’Occitane Group Service Cloud delivery for Japan and France (2023-2024), changes coming from headquarters and from the APAC teams went through one validation circuit. The mechanism is simple. With one circuit, a request from headquarters and a request from an APAC team are classified with the same questions and ship in the same release. With two circuits, each side believes it owns the shared objects, and the conflict shows up in production.
Change tiers by blast radius
Classify changes by what they can break. Who asks, and how urgent it feels, do not enter into it.
| Tier | Scope | Examples | Approval |
|---|---|---|---|
| Platform risk | Shared infrastructure, cross-org integrations, security and sharing model | Org-wide defaults, a new integration touching several clouds | Review board before any environment: a design authority, a security lead, a business owner with cross-unit authority. Three people, not twelve. |
| Domain risk | One cloud or business unit, with possible effects on its neighbours | A Flow on a shared object, a prompt template used by several teams, an API contract change | Domain owner, plus a written rollback plan |
| Isolated change | No cross-system dependency | A field on a non-shared object, a report, a dashboard, a permission set within one group | One approver, light review |
The tier itself needs governance. The easy way around a heavy process is to call your own change isolated. The answer is a mandatory impact assessment with plain questions. Does the change touch a shared object? Does it modify an API contract? Does it change who can see or edit which records? Does it change what an agent can do? The answers set the tier. The requester’s preference does not.
Release governance by environments and gates
A change board that reviews every deployment every week will be bypassed by the first team under delivery pressure. Governance that holds is built into the environments.
The pattern: a full sandbox that mirrors production, and a deployment path where automated checks run at the gate. Changes that pass the checks and sit below the risk threshold ship on the normal cadence. Changes that raise a flag go to a person. Human review becomes the exception.
The checks are ordinary engineering practice: static analysis on Apex, a Flow complexity limit above which a design review is required, API version checks, and a test coverage threshold the team sets and enforces. The sponsor does not need to configure any of this. The sponsor needs to know which checks run, what triggers a human review, and who is allowed to override a failed gate.
Release cadence is a governance decision too. A fixed release window with a short freeze before it makes the platform predictable and leaves an audit trail: every change in a release is documented, tested and attributable to someone.
AI changes go through the same door
Agentforce adds change surfaces that look like settings and behave like business logic. The agent’s scope (its topics) decides what it can be asked about. Its actions decide what it can do: update an Opportunity, send an email, call an external system. Its instructions decide how it behaves. Prompt templates in Prompt Builder shape what it writes. An undocumented instruction change is the equivalent of an undocumented rule in a Flow.
So they follow the same change control. Before a build starts, the agent scope is written down. Before production, the agent is tested against pass and fail criteria defined in advance. Any action that modifies financial records or sends an external message keeps a human in the loop. Prompt templates are reviewed on the same release cadence as everything else, and an action that writes records is never classified as isolated. The Prompt Builder governance note goes further on templates.
Governance stays with the client
An integrator can build. It should not hold the decision rights. When admin rights, change approval and release management stay with the integrator after go-live, every small change becomes a quote and a schedule negotiation, and nobody inside knows why the org is configured the way it is.
Three things stay in-house: the permission model (who can see and change what), the change approval rule, and release management. Large new builds and short specialist work can go to a partner, on two conditions. The design intent is written into the client’s own standards, and admin rights come back when the project ends. No contract clause replaces an internal owner who can say no.
What to check
- Can you name the person who decides at platform, domain and change level, and the delay for an escalation?
- Who sets the tier of a change: the requester, or an impact assessment?
- Which checks run at the release gate, and who may override a failed one?
- Are agent scope, actions, instructions and prompt templates in the same change log as Flows?
- After go-live, who holds admin rights and release management: your team or the integrator?