Salesforce Governance Framework: Decision Rights, Standards and Cadence

Governance gets framed as a discipline problem. It is closer to a scheduling problem, and the schedule is not yours.

Salesforce ships three seasonal releases a year, and every org receives them whether or not anyone asked. Retirements land on their own calendar: Salesforce’s public list of past product and feature retirements shows six features reaching end of life between February and June 2026 alone, and Workflow Rules and Process Builder support ended on 31 December 2025. Then there is unscheduled change. A practitioner post in May 2026, which drew 186 votes and 76 comments, described mandatory MFA for all users, phishing-resistant MFA for admins, step-up authentication on reports, auto-containment of high-risk connections and email domain verification arriving across roughly twelve weeks between April and July 2026. The most upvoted reply reported revising an implementation plan three times because the requirements kept moving between required and recommended.

An org absorbing that much external change also absorbs internal change: every field an admin adds, every flow a partner deploys, every permission set someone clones on a Friday.

Salesforce governance is the set of rules determining who may change what, against which standards, and on what review rhythm. It exists because change arrives faster than any individual can evaluate it, and without a framework the accumulated result is drift.

Salesforce governance splits into two domains that share one name

The word covers two disciplines that need separate owners, and conflating them is why governance charters sprawl without deciding anything.

Data governance answers whether the records are trustworthy: stewardship, duplicate rules, matching policies, quality ownership.

Platform governance answers whether changes to the system are controlled. Who approved this new object. Which standard says a validation rule belongs here rather than in a flow. Whether anyone checks that the 40 reports built last quarter are still opened.

This page covers the second. It assumes the first has its own owner, because a single forum attempting both will do neither on any useful timescale.

Well-Architected now names five pillars, and most content still cites three

Anyone building a governance framework usually anchors it to the platform vendor’s own architecture guidance, which makes the current state of that guidance worth checking rather than recalling.

Salesforce’s Well-Architected framework has been rebuilt. The Architecture Center presents five pillars and an Agentic Enterprise lens, described as helping architects navigate trade-offs and make sound architectural decisions in the agentic era. Salesforce states the framework addresses humans, agents and platforms working together inside governed business systems, and names ongoing governance as one of its three intended uses alongside design reviews and trade-off conversations. The pillars, in Salesforce’s own words:

Check the Change Log before reusing any existing charter. Every pillar there is listed as Published rather than Updated, which marks this as a new framework rather than an edit to an older one. Salesforce does not document what it supersedes, so the practical test is simple: open your governance standards and see whether the quality dimensions they name match the five above. Anything written earlier, including guidance produced by an AI assistant trained before the change, will describe a different structure.

Two pillars carry the sharpest governance consequences. Resource and Cost Optimization gives budget a seat in architecture review, which matters in a consumption-priced era where an ungoverned agent or data pipeline produces a bill rather than a performance complaint. Fairness makes transparency and accessibility architectural properties subject to review, rather than compliance paperwork handled after launch.

Salesforce’s own summary of why the pillars travel together is the most quotable line in the framework: a solution that is secure but brittle under load, or efficient but opaque in its decisions, is not well-architected.

A working framework answers three questions, not one

Most published governance frameworks describe a body, usually a Center of Excellence, and stop. The body is the venue. It is not the framework. A framework specifies what gets decided, by whom, against what, and when.

Three components carry that:

Decision rights assign each category of change to a named approver, so that no change waits for a meeting that was not going to discuss it.

Standards convert accumulated opinion into written, testable rules, so approval is a comparison rather than a debate.

Cadence gives each decision type a scheduled venue, so the framework runs on a calendar rather than on escalation.

Remove any one and the other two degrade. Standards without decision rights produce documents nobody enforces. Decision rights without cadence produce a queue. Cadence without standards produces a recurring meeting that relitigates the same questions.

How the body itself is structured, staffed and chartered is a separate subject covered in building a Center of Excellence, and project-level role assignment sits in the implementation RACI. What follows is the decision system those structures operate.

Decision rights assign each change class to a named approver

The failure mode this prevents is specific: every change routed to the same forum, which then becomes a bottleneck, which is then bypassed. Bypass is the real risk, because a governance process people route around produces worse outcomes than no process, having also consumed the time.

The remedy is to classify changes by blast radius and pre-assign authority. A workable starting matrix:

Two design rules make this hold. Every row names a person rather than a committee, because a committee cannot be paged. And the top row grants real autonomy: if an admin cannot build a report without raising a ticket, the framework will be abandoned within a quarter.

The matrix also states, by omission, who does not decide. That is its most useful property in practice, and the reason it should be published rather than assumed.

Standards turn approval into a comparison rather than an argument

A standard is only useful if it can be checked without its author present. That rules out most of what organizations call standards, which are preferences recorded informally and enforced by whoever remembers them.

Testable standards for a Salesforce org fall into four groups.

Naming and metadata hygiene. Field and object API naming conventions, mandatory description fields, required help text on any field a user sees. These are checkable by query and are the cheapest standards to enforce automatically.

Automation placement. Which tool owns which job, stated as a rule rather than a preference: where validation belongs, when a flow becomes Apex, what may run synchronously. Without this, the same requirement gets solved four different ways by four different people, and technical debt accumulates as inconsistency rather than as bad code.

Security and access. Permission sets over profiles, least privilege by default, a documented owner for every permission set group. The detail belongs in a security review, and governance’s role is to require that the review happened.

Environment and release. What must exist in a sandbox before promotion, what test evidence accompanies a change, what the rollback path is. That connects directly to sandbox strategy and makes release a check rather than a negotiation.

The test for any candidate standard is whether a reviewer who disagrees with it could still apply it consistently. If applying it requires the author’s judgment, it is guidance, not a standard, and it should be labeled that way so nobody pretends otherwise. Automated checks make standards cheap to apply at volume, which is the argument for AI-assisted code review against a published rule set rather than against reviewer preference.

Cadence gives every decision type a scheduled venue

Cadence is the component most often missing, and its absence is why governance frameworks decay into escalation paths.

Four rhythms cover a normal org:

Weekly, intake and triage. New requests classified against the decision rights matrix and routed. The output is a routing decision, not a solution.

Fortnightly, design review. Structural and integration changes reviewed against standards. Attendance is the architect plus the requester. This is the forum the matrix protects by keeping small changes out of it.

Per release, readiness. Three times a year, Salesforce ships. Someone reads the release notes against your org’s configuration and your automations, and produces a list of what to test and what to turn off. Skipping this converts a scheduled event into an incident.

Quarterly, drift review. The only rhythm that looks backward. What was built last quarter, what is unused, what standards were bypassed and why. Bypasses are data about the framework, not misconduct: a standard bypassed repeatedly by competent people is usually wrong.

The quarterly review is where governance connects to measurable outcomes, because it is the point at which an org assessment becomes an action list and unused configuration becomes an org cleanup with an owner.

Agents become governed objects with their own review rhythm

Deployed agents change what governance has to cover, and the change is structural rather than incremental.

A field has one behavior. An agent has a range of behaviors that depends on what it reads, which actions it holds and how it was instructed. Three governance consequences follow.

Agent-affecting change becomes its own class in the decision rights matrix, because a modification to an object an agent reads is a modification to the agent, even when nobody edited the agent. A field renamed, a picklist value added, a sharing rule tightened: each can alter agent behavior without appearing in any agent-related change log.

Agent review needs a rhythm of its own, closer to weekly than quarterly during early operation, because agent failures surface in conversation transcripts rather than in error logs.

And Well-Architected’s Fairness pillar now gives transparency and equitable treatment explicit architectural standing, which is directly relevant to a system that answers customers in natural language.

Ownership, escalation and the post-go-live operating model for agents are covered in Agentforce governance. The point here is narrower: the decision rights matrix needs a row for agents, and most existing frameworks do not have one.

Drift appears before outage, which is why the framework is preventive

The relationship this page rests on is that governance prevents org drift and debt. Both accumulate silently, which is what makes them expensive.

Ungoverned orgs do not fail dramatically. They accumulate fields nobody populates, automations nobody can trace, reports nobody opens and permission sets nobody owns. Each individual addition was reasonable. The aggregate is an org where every change costs more than the last one, because the impact of any modification is no longer knowable without investigation.

That is the practical case for the framework, and it is a cost argument rather than a compliance one. Decision rights reduce the number of changes made without evaluation. Standards reduce the variance between changes. Cadence ensures someone looks at the accumulation before it compounds. None of the three produces visible value in the quarter it is introduced, which is precisely why governance is usually adopted after an incident rather than before.

Organizations running ongoing change without a dedicated platform team can route the business-as-usual lane through the Support Agent for BAU work, which handles triage, dependency and impact analysis, fix generation, testing and documentation for bugs and enhancement requests. Impact analysis on every request is the part that matters for governance, because knowing what a change touches is the precondition for deciding who approves it.

Recap. Salesforce ships three releases a year plus unscheduled change, so governance responds to a rate you do not set. Well-Architected now has five pillars, Trust, Reliability, Operational Excellence, Resource and Cost Optimization and Fairness, replacing the three-part framing most documents still cite. A framework needs decision rights, standards and cadence together. Agents require their own row in the matrix and their own review rhythm.

Key facts

FAQ

What is a Salesforce governance framework?

A Salesforce governance framework defines who may change what, against which written standards, and on what review rhythm. It combines three components: decision rights assigning change classes to named approvers, testable standards, and a cadence giving each decision type a scheduled venue rather than an escalation path.

How is platform governance different from data governance?

Data governance addresses whether records are trustworthy, covering stewardship, duplicates, matching and quality ownership. Platform governance addresses whether changes to the system are controlled, covering approval authority, configuration standards and release rhythm. Most published Salesforce governance material describes the first while using the general term.

Who should approve Salesforce changes?

Approval should vary by blast radius. Reversible local changes such as reports and list views need no approval. Additive changes go to a platform owner. Structural, integration and irreversible changes go to an architect, with security sign-off for integrations. Naming an individual rather than a committee keeps decisions fast.

How often should a Salesforce governance board meet?

Four rhythms work: weekly intake and triage for routing, fortnightly design review for structural changes, release readiness three times a year aligned to Salesforce releases, and a quarterly drift review examining what was built, what is unused and which standards were bypassed.

Do AI agents change Salesforce governance requirements?

Yes. Agents need their own class in the decision rights matrix, because changing an object an agent reads changes the agent without editing it. Agent behavior surfaces in conversation transcripts rather than error logs, so review runs closer to weekly than quarterly during early operation.

What does weak Salesforce governance actually cost?

Ungoverned orgs accumulate unused fields, untraceable automation, abandoned reports and unowned permission sets. Each addition was individually reasonable. The compound effect is that every subsequent change costs more, because the impact of any modification cannot be determined without investigation first.