Preparing for Salesforce's seasonal releases: previews and testing

Preparing for a Salesforce seasonal release means using the preview window to find what will change in your org before production is upgraded. Put a sandbox on the preview and read the release notes for the products you license. Test your critical processes there, and work through the Release Updates page in Setup. Then tell users what changes for them. A named owner and a short checklist make this routine three times a year.

This guide covers Salesforce's own upgrades. Moving your team's changes from sandbox to production is a separate discipline, covered in our release management guide.

How do Salesforce's three seasonal releases actually work?

Salesforce ships three major releases a year, named Spring, Summer and Winter, and upgrades every customer org to each one. You cannot skip or postpone a release, so the useful question is how early you see it.

Each cycle follows roughly the same sequence. Salesforce publishes key dates, then upgrades sandboxes on preview instances several weeks before production. Release notes appear around the start of that preview. Production orgs are then upgraded in waves over a few weekends, and the exact maintenance window for your instance is listed on Salesforce Trust (trust.salesforce.com).

Treat the Trust maintenance calendar as the authority for your dates rather than a blog post or a partner's summary. Your production instance, and each sandbox's instance, can be upgraded on different weekends.

Which sandbox should get the preview, and how?

Pick the sandbox that most resembles production and has the integrations you need to test. Then make sure it is on a preview instance before the cutoff. Salesforce publishes a Sandbox Preview Instructions article for each release, and its steps change, so read the current one.

A sandbox's instance decides whether it is upgraded early. In Setup, the Sandboxes list shows a Release Type column telling you whether each one is on a preview or non-preview instance. The usual way to change that is to create or refresh the sandbox before Salesforce's stated cutoff. Salesforce's help articles say a refresh after the cutoff will not bring the sandbox onto the preview, and that exceptions are not made.

• Preview a Partial Copy or Full sandbox when you need realistic data and working integration endpoints.
• Keep at least one sandbox on the current release if a project is mid-deployment and cannot absorb a version change.
• Remember that a refresh wipes work in progress, so warn builders before you refresh for the preview.
• Pre-release Developer Edition orgs let you try new features early, but they hold none of your customizations.

Which sandboxes you own depends on your edition and contract. If you are unsure whether a Full or Partial Copy sandbox is included, confirm with your Salesforce account team.

How can you read the release notes without reading every page?

Read them as a filter, not a book. Start with what is being enforced or retired, then narrow everything else to the products and editions you actually use.

The release notes run to hundreds of pages, and most of it will not touch your org. The online notes can be filtered by product and edition, which removes much of the noise. Work in this order:

• The Release Updates section, because these items change existing behavior on a fixed schedule.
• Retirements, cross-checked against Salesforce's separate Active Product and Feature Retirements list.
• Changes to features your users rely on daily, such as Lightning pages, Flow, reports and email.
• API, security and authentication changes that could affect integrations or single sign-on.
• New features worth a later backlog item. Note them, but do not switch them on during the preview.

Capture each relevant item in one shared list with three columns: what changes, who is affected, and what you need to test. That list drives the rest of the cycle.

What should you test in the preview sandbox?

Test the processes that would hurt most if they broke, not every screen in the org. A short, repeatable regression script beats an exhaustive one nobody finishes.

• Revenue and service paths: lead to opportunity, quote, case creation, routing and closure.
• Integrations: inbound and outbound syncs, middleware jobs, and anything authenticating with connected apps.
• Managed packages from AgentExchange (formerly AppExchange), especially ones that add triggers or Lightning components; check the vendor's release statement too.
• Custom Apex, Visualforce and Lightning Web Components, including your Apex test classes run in full.
• Flows with complex logic, scheduled paths or record-triggered entry conditions.
• Reports and dashboards leadership relies on, plus any email templates or document generation.

Run the script as real user profiles, not only as an administrator, because permission changes often show up there first. If you already keep acceptance test scripts from past projects, reuse them here rather than writing new ones each season.

How should you handle Release Updates and their enforcement dates?

Treat each Release Update as a small project with a deadline. Test it in a sandbox, activate it in production on your schedule, and avoid letting Salesforce enforce it on its own.

You find them in Setup by searching Quick Find for Release Updates. The page groups them by status, so you can see which still need action and which are close to enforcement. Each update describes what changes and gives a date to complete steps by. Many offer a test run that switches the change on so you can observe its effect.

• Turn on the test run in a sandbox first; Salesforce notes sandbox test-run periods can end before the production deadline.
• Run the regression tests that touch the affected feature, then fix anything that breaks.
• Activate the update in production yourself at a quiet time, with the person who tested it on hand.
• Record the date, the result and any follow-up work in your change log.

Check the page between releases as well. Updates can be added or have their dates changed, and an Overdue item is a sign that ownership has slipped.

What happens when Salesforce retires a feature you use?

A retirement usually comes with a long notice period, so the risk is ignoring it rather than being caught by surprise. Turn each one into a dated item on your roadmap with an owner.

Salesforce keeps a help article listing active product and feature retirements, and another for past ones. Check it each cycle and match entries against what your org uses. Retirement can mean different things: some features stop working, while others keep running without support or fixes. Read the specific notice before you decide how urgent it is.

Workflow Rules and Process Builder are the most common current example. Salesforce ended support for both at the end of 2025, and our migration guide explains how to move that automation to Flow. Renamed or replaced AI features are another, and our Einstein vs. Agentforce article sorts out which products changed.

How do you tell users what is changing?

Send one short, plain-language note per release that covers only the changes users will notice. Most users need three or four bullet points, not a feature tour.

Build the note from your shared list of relevant items. Say what will look or behave differently, when it happens, and who to ask. Add a screenshot where a page layout or button moves. For larger changes, a short session or an in-app prompt works better than an email nobody opens.

Hold back new features you have not yet configured. Announcing them before they are ready sets expectations you then have to walk back. Our change management and training plan guides cover bigger rollouts.

Who should own release readiness: your admin or a partner?

Someone specific has to own it, or it will not happen. In a small org, that is usually the admin with a calendar reminder; in a busier one, it often sits with a managed services partner.

The work peaks three times a year and competes with project deadlines, which is why it slips in a stretched team. An in-house admin brings knowledge of how the business really uses the org. A managed services team brings a repeatable process and cover when people leave or take leave. Many companies combine the two: the partner runs the cycle and testing, and the admin owns user communication and sign-off.

If you would rather hand this off, seasonal release review can be written into a managed services agreement with a Salesforce partner. Whatever the arrangement, write the owner's name on the checklist.

What does a repeatable release readiness checklist look like?

Keep it to one page and reuse it each season. The value comes from running the same steps every time, not from making the list longer.

• Confirm the release dates and your production and sandbox maintenance windows on Trust.
• Choose the preview sandbox and refresh or create it before the cutoff.
• Filter the release notes and list relevant changes, enforced updates and retirements.
• Ask AgentExchange vendors whether their packages are ready for the new version.
• Run regression scripts as real user profiles, including integrations and Apex tests.
• Test each Release Update in sandbox, then activate it in production on a planned date.
• Add each retirement that affects you to the roadmap with an owner and target release.
• Send the user change note and brief support staff on likely questions.
• Smoke-test production on the first working day after the upgrade.
• Update this checklist and the test scripts with what you learned.