5 min read
Three times a year, Salesforce updates every org whether anyone on your team read the notes or not. Preview sandboxes get the new version weeks ahead of production, which makes release season one of the few risks in the platform you can retire almost entirely with a scheduled hour of work.
Why the sandbox pass is the whole job
You cannot decline a release, and you cannot roll one back. What you can do is see it early. A preview sandbox on the new version gives you a window in which a break is a task on a list rather than an incident during month-end close.
The goal of the pass is not to read every release note — there are hundreds and most will never touch you. It is to walk your own critical paths on the new version and confirm they still behave.
Six things worth an hour of sandbox time
Order matters here: the first four are checks on what you already depend on, the last two are decisions about what is being taken away.
- Your top three business-critical Flows, run end to end with real record shapes — not a single happy-path test record.
- Every integration user and connected app: API behaviour and permission changes hit these before they hit any human user.
- Apex test suites in full, with attention to anything asserting on standard-object behaviour or error message text.
- Page layouts and Lightning pages on the objects your team lives in, checked on both desktop and mobile.
- Any feature the notes mark as retiring or enforced-on, and what the migration path for it is.
- Permission and sharing changes, especially where a release tightens a default your configuration was quietly relying on.
The two that quietly break existing flows
The first is a change in behaviour rather than a change in features: a validation rule, a required field, or a sharing default that becomes stricter. Nothing errors when you save it, and nothing looks different on a page. The Flow simply starts failing at the step where it writes, and only for the subset of records that trip the new constraint. This is why the Flow check has to use realistic record shapes — a clean test record will pass happily.
The second is deprecation with a grace period. A feature gets marked retiring, the release still supports it, and the automation keeps working — so the check passes and nobody records the finding. Two releases later the support is gone and the context is lost. If a pass turns up something on a retirement path, the output is a scheduled migration ticket, not a note that it still works.
A routine you can actually repeat
Refresh a full or partial-copy sandbox onto preview as soon as it is available. Keep a written list of the critical paths for your org — it changes maybe twice a year — and walk it. Log what you find as tickets with the release name attached, so next season starts from a list instead of from memory.
Under an hour, three times a year, and release season stops being something that happens to you.