Salesforce Governance

Salesforce Change Control Process: The Definitive Guide

Q: What is change control in Salesforce?

Change control in Salesforce is the formal process for requesting, reviewing, approving, and documenting changes to a Salesforce org before they are deployed to production. It ensures that every production change was authorised by the appropriate stakeholders, tested in a non-production environment, documented with its business justification and risk assessment, and tracked in an audit trail that persists after the change is deployed. Change control is distinct from the technical deployment process — it is the governance layer that sits on top of deployment tooling and ensures that the human decision to deploy a change was made deliberately and accountably.

Q: What is a Salesforce change freeze?

A change freeze is a defined period during which production changes are prohibited or subject to significantly elevated approval requirements. Change freezes are typically implemented around major business events (end of financial quarter, major product launches, peak trading seasons) where the risk of a production incident is disproportionately high and the business cannot absorb downtime or degraded performance. During a change freeze, only emergency changes with explicit senior approval are permitted to reach production. Change freezes should be planned in advance, communicated to the entire team and business stakeholders, and have a clear start and end date.

Q: How should Salesforce change requests be documented?

A Salesforce change request should document: the change title and description (what is changing and in which components), the business justification (why is this change needed), the technical approach (how will it be implemented), the risk assessment (blast radius, reversibility, test coverage), the test plan and results (what was tested, in which environment, and by whom), the rollback plan (how will the change be reversed if it causes an issue), the deployment window requested, and the CAB approval with approver identity and timestamp. This documentation should be stored in a system that is accessible to the release team and available for audit without requiring access to the Salesforce org itself.

Q: What is an emergency change in Salesforce and how is it handled?

An emergency change is a production change that cannot wait for the next scheduled release window because it addresses a critical production issue that is causing material business impact. Emergency changes bypass normal CAB review but still require explicit approval — typically from a named senior stakeholder who can assess the risk and authorise the exception. The emergency change process should require: a named authoriser, a brief written justification of why the change cannot wait, a simplified rollback plan, and a retrospective review in the next scheduled CAB meeting to understand what caused the emergency and whether process improvements would prevent recurrence. Emergency changes that become frequent are a signal that the standard release cadence is too slow for the team's change velocity.

Q: How do you integrate Salesforce change control with Jira or ServiceNow?

Salesforce change control integrates with Jira or ServiceNow by using those platforms as the system of record for change requests — creating a Change ticket type with required fields (risk assessment, test evidence, rollback plan, CAB approval status), linking each Salesforce deployment to its corresponding change ticket, and using the ticket's approval status as a gate in the deployment pipeline. The strongest integration is where a production deployment literally cannot execute without a linked approved change ticket — enforced by tooling rather than by human process. This removes the weakest governance failure mode: the engineer who deploys under pressure without completing the approval process.

By CloudEzee Technologies · June 2026 · 15 min read

Change control is the governance discipline that turns a Salesforce deployment from a technical act into an organisational decision. Without it, production changes happen informally — fast when they work, catastrophic when they do not. With it, every production change has an owner, an approver, a documented test record, and a rollback plan. This guide covers the complete Salesforce change control process: RFC workflows, CAB operation, change freeze management, emergency tracks, and the documentation practices that make governance real rather than performative.

What Change Control Is (and Is Not)

Change control is not the same as deployment tooling. Your CI/CD pipeline, your Change Sets, or your release management platform are the mechanism that moves changes from one environment to another. Change control is the governance layer that determines whether a change is authorised to move at all.

A team can have excellent deployment tooling and no effective change control — deployments run reliably but without the business having visibility or input into what is being deployed. A team can also have strong change control and poor deployment tooling — every change is carefully reviewed and approved, but the deployment process itself is manual and error-prone. The goal is both: a deployment process that executes reliably and a change control process that ensures only the right changes enter that process at the right time.

The Change Request Workflow

Every production change begins with a change request (CR) or Request for Change (RFC). The CR is the single record that tracks a change from initial request through deployment and post-deployment verification. Its structure should be standardised across the team so that the CAB can review changes consistently and the audit trail is complete.

A standard Salesforce CR workflow:

Initiation: Developer or admin creates the CR, describing what is changing, why, and which components are affected.
Risk assessment: CR owner completes the risk assessment (blast radius, reversibility, test coverage) and assigns a risk rating (Standard, Elevated, Emergency).
Technical review: A peer technical review confirms the approach and identifies any technical risks not visible in the description.
Testing: Change is developed and tested in the appropriate environment chain. Test results are recorded in the CR.
UAT: For changes affecting business users, UAT sign-off is recorded in the CR before it proceeds to CAB review.
CAB review: CR is presented to the CAB with the complete package — description, risk assessment, test results, rollback plan. CAB decides: approved, conditional, or rejected.
Deployment: Approved CR is deployed in the next scheduled deployment window.
Post-deployment: Verification steps are completed and recorded in the CR. Any incidents are linked to the CR. CR is closed.

CAB Structure and Operation

The CAB does not need to be a large or formal body. Its minimum composition is three people with complementary perspectives: someone who understands the technical risk (a senior developer or architect), someone who understands the business impact (a stakeholder or product owner), and someone who owns the release process (the release manager). For significant compliance-related changes, adding a compliance or security representative to the CAB review is appropriate.

CAB meetings should be time-boxed and structured. A standard format: each CR is presented by its owner in two minutes (what is changing, what is the risk, what is the rollback plan), followed by questions from CAB members, followed by a decision. Most changes at a well-run organisation take less than five minutes in the CAB — detailed discussion is reserved for elevated-risk changes or changes with incomplete documentation.

CAB decisions should be recorded synchronously — not just a verbal approval but a timestamped record of who approved what and on what date. This record is your compliance evidence and your first reference point if the change causes an issue after deployment. See our release governance framework for the full audit trail requirements.

Change Categories and Routing

Routing changes through different approval tracks based on risk level keeps governance proportionate. Three categories cover most Salesforce change scenarios:

Standard changes are low-risk, well-understood changes that follow a pre-approved pattern — adding a standard field to a custom object, updating report filters, adding a new user with a standard permission set. Standard changes may have a simplified approval path (manager approval rather than full CAB) or a pre-approved standard change library where specific change types are pre-approved at the category level rather than reviewed individually.

Elevated changes are changes with meaningful blast radius, limited reversibility, or lower test coverage — flow modifications on core objects, permission set changes affecting broad populations, new integrations, changes during elevated business periods. These go through full CAB review with complete documentation.

Emergency changes are changes required to restore production service or address a critical compliance issue that cannot wait for the next scheduled release. These follow the emergency track: named senior approver, abbreviated documentation, immediate deployment, mandatory CAB retrospective review.

Change Freeze Management

Change freezes are planned periods when production changes are prohibited or subject to the most restrictive approval requirements. They are a legitimate governance tool — not bureaucracy — when the business cannot absorb the risk of a deployment incident during a critical period.

Common Salesforce change freeze triggers:

End of quarter or financial year (sales teams cannot be disrupted during close)
Major product or platform launch (all engineering focus on launch quality)
Peak trading seasons (Black Friday, end of tax year, back to school)
Salesforce seasonal releases (the platform is changing — non-essential org changes should wait)
Major data migrations or go-lives that require stable platform state

Change freeze periods should be planned into the release calendar at the start of the year, communicated broadly, and enforced consistently. A change freeze that is routinely bypassed provides no governance benefit and trains the team to treat governance controls as optional.

Integrating Change Control with Your Deployment Pipeline

The most effective change control implementations integrate with the deployment pipeline so that governance is enforced by tooling rather than by human discipline. The strongest implementation: a production deployment literally cannot execute without a linked, approved change request in the change management system.

For teams using Jira: configure your deployment pipeline to require a linked Jira issue in "Approved for Production" status before a deployment to production can proceed. For teams using ServiceNow: use the ServiceNow integration with your CI/CD platform to gate production deployments on approved Change tickets. For teams using purpose-built Salesforce tools: platforms like DeployEzee include change tracking built into the deployment workflow.

See also our guides on the Salesforce release manager role and Salesforce UAT for the human process components that sit alongside the tooling integration.

Frequently Asked Questions

What is change control in Salesforce?

Change control is the formal process for requesting, reviewing, approving, and documenting changes before they reach production. It ensures every production change was authorised, tested, documented with a rollback plan, and tracked in an audit trail. It is the governance layer on top of deployment tooling.

What is a Salesforce change freeze?

A planned period during which production changes are prohibited or subject to the most restrictive approval requirements — typically around major business events like end of quarter, peak trading seasons, or major product launches. Change freezes should be planned annually, communicated broadly, and enforced consistently.

How should Salesforce change requests be documented?

A change request documents: what is changing and in which components, the business justification, the risk assessment, the test plan and results, the rollback plan, the deployment window, and the CAB approval with approver identity and timestamp. Stored outside the org in a system accessible for audit.

What is an emergency change in Salesforce and how is it handled?

An emergency change addresses a critical production issue that cannot wait for the next release window. It requires a named senior approver, a brief written justification, a simplified rollback plan, and a CAB retrospective review after the fact. Emergency changes should be rare — frequent emergency changes signal that the standard release cadence is too slow.

How do you integrate Salesforce change control with Jira or ServiceNow?

Use those platforms as the system of record for CRs, link each deployment to its CR, and configure the deployment pipeline to require a linked approved CR before production deployment can execute. The strongest implementation makes it technically impossible to deploy to production without a completed approval workflow.