How to Build a Salesforce Org Governance Program

Most Salesforce orgs start with one admin and no governance. That is fine when you have 20 users and your CRM holds a few thousand records. It stops working around the 50-person mark, when you add a second admin, your first integration, or your first compliance requirement.

Salesforce org governance is the set of policies, processes, and tooling that determines who can change the org, how changes get approved and deployed, and how you verify that the org stays in the state it is supposed to be in. This post covers what a governance program actually looks like for a growing B2B company: the four pillars it rests on, the specific practices under each pillar, and how to implement them without making your org unmanageable to operate.

---

Why Governance Breaks Down at Scale

A Salesforce org without governance does not fail all at once. It accumulates problems.

A user gets a permission "just for this project" that never gets removed. A developer tests a flow in production because they were in a hurry. An admin changes a profile to fix a support ticket without documenting what they changed. Six months later, no one can explain why the VP of Sales has Modify All Data access, or why a flow that was supposed to be deactivated is still running.

The governance problems that cause the most damage are:

• Permission creep: Users accumulating access over time, never having it removed
• Undocumented changes: Configuration changes made directly in production without review or a record of why
• No change ownership: Multiple admins with the ability to change anything, no one responsible for reviewing what changed
• Reactive monitoring: Finding out about security configuration changes after something breaks, not before

None of these require malicious intent. They happen in well-run orgs with competent admins. They are a natural consequence of operating without a governance structure.

---

The Four Pillars of Salesforce Org Governance

A complete governance program covers four areas. Smaller orgs can start with one or two and add the rest as they grow.

1. Access Control Governance

What it is: Formal policies for how user access is granted, modified, and removed.

The core components:

A permission model defines what profiles and permission sets exist and what each one is for. Every permission set should have a documented owner and business purpose. "What does this permission set do and who should have it?" should have a written answer.

An access request process defines how users get access. Even a simple process (manager emails the admin team, access is provisioned within 24 hours and documented in a spreadsheet) is better than no process. Without a process, access gets granted ad hoc and never reviewed.

A user offboarding checklist ensures that access is removed when someone leaves or changes roles. The most common permission creep source is users who changed departments and kept their old permissions because no one ran a cleanup.

A quarterly access review is a scheduled review where you look at who has what access and verify it matches current job responsibilities. For each profile and permission set group, ask: does anyone currently assigned this access no longer need it?

2. Change Management Governance

What it is: Policies for how configuration changes get proposed, reviewed, tested, and deployed.

The core components:

A sandbox-first rule means that no configuration change goes to production without being tested in a sandbox first. This is the single highest-impact practice for avoiding production incidents. Even a partial sandbox (Developer or Developer Pro) is enough for most change testing.

A change window policy defines when changes can be deployed to production. Common patterns: changes go to production Tuesday through Thursday, never Friday or Saturday. Changes during a sales quarter close are frozen. Changes to security settings require an additional review step.

A change log is a simple record of what changed, when, who made the change, and why. This does not need to be complex: a shared spreadsheet with columns for Date, Changer, What Changed, Why, Jira/ticket number is sufficient. The purpose is traceability.

Deployment tooling enforces the sandbox-first rule by making production deployments happen through a controlled mechanism rather than direct Setup edits. Salesforce provides Change Sets, DevOps Center (included with all editions as of Spring '24), and Outbound/Inbound Change Sets. Third-party options include Copado, Gearset, and AutoRABIT. For teams with developers, source-driven deployment via the Salesforce CLI is the most auditable approach.

3. Monitoring and Alerting Governance

What it is: Ongoing visibility into what is actually happening in your org, not just what you intended to configure.

The core components:

The Setup Audit Trail is the foundation. It records every configuration change made in Setup: who changed what, when, and from which IP address. The governance question is whether you are actively reviewing it or treating it as a last resort after something breaks.

A daily review routine for the Setup Audit Trail focuses on Security Controls, Manage Users, and Flow changes. It takes 5-10 minutes. It catches unauthorized changes the day they happen instead of weeks later.

Alerting on Critical changes closes the gap between "something happened" and "someone knows about it." Security configuration changes (MFA settings, IP restrictions, SSO configuration, connected app OAuth settings) should trigger an immediate notification, not wait for the next morning's review.

Retention and archiving addresses the Setup Audit Trail's 180-day limit. Exporting the audit trail monthly and storing it outside Salesforce gives you a change history that survives past Salesforce's retention window. This is required for most compliance frameworks (SOC 2, ISO 27001, GDPR data processing accountability).

A monitoring process that depends on one person checking a UI manually is fragile. Continuous, automated monitoring is more reliable. For a detailed walkthrough of what continuous change monitoring looks like in practice, see How to Monitor Salesforce Org Changes.

4. Documentation Governance

What it is: Keeping an accurate record of your org's intended state so you can detect and investigate deviations.

The core components:

An org dictionary documents each custom object, field, and automation: what it does, who owns it, and whether it is still in use. Unused fields, obsolete flows, and abandoned automation are common governance debt items. A documented inventory makes cleanup tractable.

A permission model map documents each profile and permission set group, what it represents (job role, use case, integration), who is assigned it, and who approved it. This is distinct from the Salesforce permission model itself. It is the business context behind the technical configuration.

An integration register lists every connected app, named credential, and external system with access to your org: what it does, who owns it, what OAuth scopes it holds, and when it was last reviewed. Dormant integrations with active credentials are a persistent security risk. A register makes it obvious which apps have not been touched in 18 months.

Change documentation connects the change log from Pillar 2 to an explanation of why. If your Setup Audit Trail shows that a profile was modified on March 15, your change documentation should explain why. When a reviewer or a future admin asks "what was the business reason for this change," you should be able to answer.

---

Where to Start: Governance by Org Size

A governance program does not need to be fully implemented all at once. Here is a realistic progression:

Under 50 users:

• Implement sandbox-first for any automation or profile changes
• Keep a change log (a shared spreadsheet is fine)
• Review Security Controls changes in the Setup Audit Trail weekly

50 to 200 users:

• Formalize the access request process
• Add a quarterly access review to the calendar
• Move from manual audit trail review to automated daily monitoring
• Build an integration register

Over 200 users:

• Standardize deployment tooling (DevOps Center or equivalent)
• Implement formal change windows and approval workflows
• Add retention archiving for the Setup Audit Trail
• Document the full permission model with business context

The governance practices that matter most at small scale are the ones that prevent the hardest problems to unwind: permission creep and undocumented changes. Start there.

---

How AuditForce Fits Into a Governance Program

The monitoring pillar of a Salesforce governance program has three requirements: daily visibility into what changed, severity classification so you know what to prioritize, and alerting when something Critical happens without waiting for the next scheduled review.

AuditForce connects to your SetupAuditTrail via the Salesforce API, applies a configurable severity rules engine to every change (Critical, High, Medium, Low), and delivers a morning digest categorized by severity. Security changes (MFA, IP restrictions, SSO, connected apps) are Critical by default and trigger immediate notifications. The rules are configurable: if your org has specific administrative patterns that produce false positives, you can adjust the classification.

This replaces the "check the audit trail manually when something breaks" approach with continuous, automated monitoring that surfaces issues before they become incidents. For a growing B2B company building out a governance program, the monitoring layer is the one that catches everything the other three pillars miss.

---

The Governance Mindset

Governance has a reputation for slowing things down. A well-implemented governance program does the opposite.

When access is documented and change logs are maintained, troubleshooting takes minutes instead of hours. When monitoring catches a security change the day it happens, the response is a quick verification call instead of a full incident investigation. When deployments go through a sandbox first, production incidents from untested changes stop happening.

The overhead of governance is front-loaded. The payoff compounds. An org that has been governed well for two years is dramatically easier to operate, audit, and hand off than one that has not. Start with the practices that address your biggest current risks, build consistency before adding complexity, and treat governance as infrastructure rather than overhead.