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 DevOps Center, and review each seasonal release in a preview sandbox before it reaches production.
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.
| Sandbox | Production data | Refresh interval | Good for |
|---|---|---|---|
| Developer | None | Daily | One person building or trying out a single change |
| Developer Pro | None, with more storage than Developer | Daily | Larger builds and seeded test data |
| Partial Copy | A sample, chosen by a sandbox template | Every 5 days | Integration testing and user acceptance testing |
| Full | A complete copy, including files | Every 29 days | Final staging, performance checks and data migration rehearsals |
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. Salesforce now offers a next-generation version built directly on the platform alongside the original managed package. Developers can keep working with the Salesforce CLI against the same repository, so admins and developers share one pipeline instead of two.
| Change sets | DevOps Center | |
|---|---|---|
| Record of changes | Held in each org; no version history | Git repository with full history |
| How work is grouped | One change set per deployment, built by hand | Work items tied to user stories |
| Conflict handling | Last deployment wins | Branch, merge and conflict detection |
| Skills needed | Point-and-click only | Point-and-click, with basic Git concepts |
| Best fit | Small teams making occasional changes | Several builders, frequent releases or an audit requirement |
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.
