Understanding Salesforce Releases: Major, Minor, and How They Affect You

The Salesforce Release Calendar

Salesforce releases three major updates per year, named after seasons: Spring (January-February), Summer (May-June), and Winter (September-October). Each release delivers hundreds of new features, enhancements, bug fixes, and occasionally deprecations across all Salesforce products.

The releases are not optional. Unlike traditional enterprise software where upgrades are scheduled on the customer's timeline, Salesforce upgrades all tenants simultaneously during a maintenance window. Your production org will be upgraded whether you opt in or not — the Salesforce multi-tenant model makes per-tenant version pinning impractical at scale.

In addition to the three major releases, Salesforce deploys patch releases and hotfixes throughout the year for security issues, critical bugs, and infrastructure maintenance. These are typically smaller in scope and rarely break existing functionality.

The Preview Sandbox Window

The most operationally important aspect of the release cycle is the preview sandbox window. Before production orgs are upgraded, sandboxes with Preview enabled are upgraded approximately 4 weeks earlier. This is your regression testing window.

Not all sandboxes receive the preview upgrade automatically — you must opt in via the sandbox management settings. Best practice is to designate one sandbox as the "release preview" sandbox, opt it in to preview upgrades, and use the 4-week window to run regression tests against the upcoming release before production is affected.

What to test during the preview window: automations (flows, triggers, Apex) that interact with any feature area changed in the release, integrations that call Salesforce APIs (API version changes occasionally affect response structures), custom LWC or Aura components on any page layout being changed, and any Critical Updates that are becoming mandatory in this release.

-- Checking current Salesforce API version in your org
SELECT Id, ApiVersion, Name
FROM ApexClass
ORDER BY ApiVersion ASC
LIMIT 50
-- Classes using old API versions may be affected by
-- deprecated features in the new release

Critical Updates: The Mandatory Changes

Critical Updates are changes to platform behaviour that Salesforce introduces as opt-in changes with a future mandatory activation date. The intent is to give orgs a testing window before the behaviour becomes universal — but many orgs ignore Critical Updates until they become mandatory and then scramble to handle the behavioural change.

Critical Updates appear in Setup under Critical Updates. Each has a description of the behaviour change, an opt-in button (to activate it early for testing), and a mandatory activation date (the date after which Salesforce will activate it for all orgs regardless of opt-in status).

The correct process: review every new Critical Update when it appears. If the change affects your org, activate it in a preview sandbox immediately to assess the impact. Prioritise testing and any required code/configuration changes to be complete before the mandatory activation date. Do not wait until the deadline — orgs that activate on the mandatory date have no testing window if the change breaks something.

Reading Release Notes Efficiently

Salesforce release notes are exhaustive — 500-1,000 pages per release covering every product area. Reading them end-to-end for every release is not feasible. A structured triage approach is more practical.

Step 1 — Identify your product footprint: Your org uses a subset of Salesforce products. If you do not use Marketing Cloud, skip those sections. Focus on the product areas active in your org: Sales Cloud, Service Cloud, Experience Cloud, Platform features (Apex, Flows, APIs), and any clouds your org uses.

Step 2 — Scan for "Changed behaviour" notes: In the release notes, look for items marked as "Changed" rather than "New." Changed items modify existing behaviour and are more likely to break existing configurations than new features (which are additive). The Changed section is the highest-risk area for regressions.

Step 3 — Review the API section: If your org has custom integrations, check the API release notes for any changes to the REST, SOAP, or Bulk API versions. New API versions are released annually — if integrations are using an old API version that is approaching deprecation, the release notes are where this is flagged.

Step 4 — Check deprecations and retirements: Every release notes document has a section on deprecated and retired features. If a feature your org depends on is deprecated, you have a defined retirement timeline. This is where Workflow Rules, Process Builder, and similar retirement announcements first appeared.

Building a Release Management Process

A practical release management process for a Salesforce org does not need to be bureaucratic. These are the minimum viable practices that protect production.

Release calendar entry: Add Salesforce release dates to your team calendar 12 months in advance. Three per year, predictable. When the preview upgrade window opens (~6 weeks before production), schedule a regression testing sprint segment.

Preview sandbox designation: One sandbox is permanently designated as the preview sandbox. It receives preview upgrades. The cost: this sandbox has a different software version than production for 4 weeks three times per year. The benefit: regression issues are found before they hit production.

Regression test coverage: Maintain a set of smoke tests for critical business processes that can be run in 2-4 hours against the preview sandbox. Not full UAT — just enough coverage to catch breaking changes in the areas your users depend on most.

Critical Updates review in sprint ceremony: In the first sprint after a new release, review any new Critical Updates in Setup. Assign an owner and activation timeline for each relevant one.