Salesforce release management: sandboxes, deployments and releases

Salesforce release management is the discipline of moving changes from a sandbox into production in a controlled, repeatable way, while also preparing for the three upgrades Salesforce ships every year in Spring, Summer and Winter. In practice it means four habits: build and test in the right sandbox, keep your metadata in source control, deploy through a defined path such as change sets or Lifecycle Center (formerly DevOps Center), and review each seasonal release in a preview sandbox before it reaches production.

How do you do Salesforce release management?

You do Salesforce release management by building and testing every change in a sandbox, deploying it to production through one agreed path, and checking each Salesforce seasonal release in a preview sandbox before it reaches your org. For your own changes, a simple release process runs in this order:

• Plan: write down the change, who asked for it and who will approve it.
• Build: make the change in a Developer or Developer Pro sandbox, not directly in production.
• Track: commit the changed metadata to source control, or add it to a change set or a Lifecycle Center work item.
• Test: move the change to a Partial Copy or Full sandbox and test it as real users, with their own profiles and permission sets.
• Approve: have the business owner sign off on user acceptance testing.
• Validate: run a validation-only deployment against production before the release window, so failing Apex tests show up early.
• Release: deploy during a quiet period and tell users what changed.
• Watch: check error emails, failed Flow interviews and integration logs for the next few days, and keep the previous version ready to redeploy.

Two kinds of change hit every org

The first kind is yours: new fields, Flows, page layouts, Apex, permission changes and integrations that your team or partner builds. The second kind is Salesforce's: seasonal upgrades that arrive automatically, whether you asked for them or not. Salesforce states that every customer runs the same version, and it publishes upgrade dates on its Trust site well ahead of time.

Most orgs handle the first kind informally and the second kind not at all. An admin edits a validation rule directly in production on a Friday afternoon, and a few months later a release changes a default nobody noticed. Neither problem needs a large process to fix. It needs a small one that everyone actually follows, sized to how often you change the org and how much breaks when something goes wrong.

Pick sandboxes by what each one is for

Salesforce offers four sandbox types. All four copy your production metadata; they differ in how much data they hold and how often you can refresh them. Your edition and any add-ons decide how many of each you own, so check the contract before designing an environment plan around a Full sandbox you may not have.

A workable pattern for a mid-sized org is one Developer sandbox per builder, a Partial Copy for integration and user testing, and a Full sandbox kept as staging for anything risky. Because Partial and Full sandboxes copy real records, treat them with production-level access rules. Salesforce's Data Mask & Seed tooling can obscure sensitive fields in copies, and it is worth using before you hand testers access to customer data.

Source control and deployment paths

Source control means your org's metadata lives in a Git repository, so every change has an author, a date, a reason and a previous version you can return to. Without it, the only record of how production got to its current state is production itself. Teams that do mostly declarative work sometimes skip this step because it sounds like a developer concern, but admins benefit from it just as much when they need to answer why a Flow changed.

Salesforce gives you two native ways to move changes. Change sets send components from a sandbox to production, or between sandboxes of the same production org, over an authorized deployment connection. They are included, familiar to most admins, and fine for occasional small changes. They also have limits: the org is the only record of what was sent, components must be selected by hand, and an inbound change set deploys as a whole rather than piece by piece.

DevOps Center is Salesforce's alternative built around source control. Changes are tracked as work items, moved through a pipeline of stages with clicks, and stored in a connected Git repository that becomes the source of truth. Since Spring '26 a next-generation version has been built directly into the platform, so you turn it on in Setup instead of installing a package. The original managed package stopped taking new installs in April 2026, and from October 2026 Salesforce calls the product Lifecycle Center. Developers can keep working with the Salesforce CLI against the same repository, so admins and developers share one pipeline instead of two.

Testing before anything reaches production

Testing in Salesforce has a hard floor and a practical standard. The floor is Salesforce's own rule: Apex needs at least 75% code coverage from passing unit tests before it can deploy to production, and every trigger needs some coverage. The practical standard is higher, because coverage only proves the code ran, not that the business process still works.

• Write test scripts from the user story, in the words of the person who will do the work.
• Run the scripts in a sandbox with realistic data, including records with missing or odd values.
• Test as a user with the target profile and permission sets, never only as a system administrator.
• Check the Flows, validation rules and integrations that touch the same objects, not just the new component.
• Validate the deployment against production before the release window, so test failures surface early.
• Have a business owner sign off on user acceptance testing and record who approved what.

Schedule deployments for a quiet period, tell users what is changing, and keep someone available afterward to watch error emails, failed Flow interviews and integration logs. Small, frequent releases make every one of those steps easier than one large quarterly drop.

Reviewing the three seasonal releases

Salesforce upgrades sandboxes on preview instances roughly four to six weeks before each production release, which gives you a window to test the new version against your own customizations. Whether a sandbox lands on preview depends on its instance and when you create or refresh it, so plan a refresh ahead of the preview cutoff for the sandbox you want to use. Release notes typically appear around the same time.

The release notes run to hundreds of items, so read them with a filter rather than cover to cover. Start with the products and features you actually license, then look for anything marked as changing existing behavior. Separately, open Release Updates in Setup: these are changes Salesforce will enforce by a stated date, and many offer a test run you can switch on in a sandbox first.

Rollback thinking

Salesforce deployments do not come with an undo button, and some changes cannot be reversed cleanly at all: a deleted field loses its data, and a changed picklist value may already be written to thousands of records. Rollback therefore has to be planned before the deployment, not improvised after it.

With source control in place, rolling back usually means deploying the previous version of the affected components forward, the same way the change went in. For changes that alter data, take an export or confirm a backup before release, and prefer additive changes: add the new field and retire the old one in a later release once nothing depends on it. For features that users see, a permission set or custom setting that switches the change on lets you turn it off without a deployment.

Finally, write down who can approve a rollback and how quickly. A bad deployment that is reversed in twenty minutes is an inconvenience; the same deployment left in place during hours of debate becomes an outage.

Who should own release management

In a small org, the admin owns it, with a checklist and a calendar. As the number of builders, integrations and business units grows, release management becomes a role of its own: someone who controls the pipeline, schedules deployments, runs the seasonal review and says no to changes made directly in production. Many companies give that job to a managed services partner so it survives staff turnover. Abstrakt has been a Salesforce Consulting Partner since 2017, and release reviews are a standing part of the managed services work our U.S.-based team does.

What is the minimum release process for a small team?

A small team needs four things: a sandbox for building, one place where every change is recorded, one person who approves releases, and a calendar for the three seasonal releases. That is enough for an org with one or two admins and a few integrations.

• Build fields, Flows, validation rules and page layouts in a sandbox. Day-to-day user administration, such as adding users or resetting passwords, still happens in production.
• Keep a simple change log: what changed, why, who approved it and when it went live.
• Use change sets if your team works only with clicks. Move to Lifecycle Center or the Salesforce CLI with Git once more than one person builds at the same time.
• Release on a fixed day, outside busy hours, and tell users beforehand.
• Before each seasonal release, refresh or confirm a preview sandbox and run through your core processes.
• Write a one-line rollback plan for every change before you deploy it.

As the team grows, add a Partial Copy sandbox for user testing and put all metadata in source control. Release reviews with sandbox testing are part of Abstrakt Solutions managed services, for teams that want a partner to run this routine.