The quick version: do not read the release notes front to back. Read the Release Updates page in your own org first, because that is the list of changes that will break something on a date. Then filter the notes to the features you actually use, then check the “How To Enable” column, which is the only column that determines whether you have work to do. Ninety minutes, three times a year.
Start in your org, not in the notes
Setup → Release Updates lists changes Salesforce is enforcing, with enforcement dates, and it is scoped to your org. That is a better starting point than a document written for every customer.
Each entry tells you when it becomes mandatory and usually offers a test mechanism you can run before then. Sort by enforcement date and work the nearest ones.
The reason to start here is simple: everything on this page has a deadline attached, and almost nothing in the rest of the release notes does.
The three categories, and the one that matters
| Category | What it means for you |
|---|---|
| Enabled by default | It is happening. Test it. |
| Available but off | Optional. Read it when you have a need. |
| Release Update / enforced later | A deadline. Put it in the plan. |
“Enabled by default” is where the risk is. Those changes arrive whether you read about them or not, and they are the ones that produce the Monday morning surprise.
Everything in the “available but off” pile can wait until somebody has a problem it solves. Reading it speculatively is how ninety minutes becomes a day.
A filter that works
The release notes site lets you filter by product, by feature area, and by “enabled for” audience. Set it to the clouds you own and the “Enabled by default” filter, and the document collapses from hundreds of items to a readable list.
Then read only:
- Anything touching objects your automation runs on.
- Anything under API and integration, if you have integrations — API version deprecations are the highest-consequence items in any release.
- Anything in Flow, because Flow changes behaviour more often than anything else you rely on.
- Anything marked as a change to existing behaviour rather than a new feature.
Skip the entire “new in beta” and “pilot” sections unless you have signed up for one. Beta features change before GA and reading about them is entertainment, not preparation.
API version deprecations deserve their own pass
Salesforce retires old API versions on a published schedule, and an integration pinned to a retired version stops working. This is the single most damaging thing in any release cycle and it is easy to miss because it sits in a section most admins skip.
Find every API version in use in your org before you need to:
SELECT Name, ApiVersion FROM ApexClass WHERE ApiVersion < 50.0 ORDER BY ApiVersion
SELECT Name, ApiVersion FROM ApexTrigger WHERE ApiVersion < 50.0 ORDER BY ApiVersionAnd check what external systems are calling, which you cannot see from metadata — that comes from your integration inventory and from API usage data.
Preview windows and how to use them
Sandboxes on a preview instance get the release roughly a month early. That window is the only chance to test against the new version before production moves, and getting onto it requires your sandbox to be on the right instance, which is decided at creation or refresh time, not on demand.
If preview testing matters to you, that is a calendar item before the refresh deadline, not a decision you make when the release notes land.
What to actually do with what you find
- Release Updates with a near deadline → a ticket, with the enforcement date as the due date.
- Enabled-by-default changes touching your objects → test in a sandbox on preview.
- API deprecations → inventory, then upgrade plan.
- New features you want → a backlog item, not a release task. Adopting a feature is a project.
- Everything else → nothing. Deliberately.
The discipline is in step five. Most release-notes anxiety comes from treating a catalogue of everything Salesforce built as a list of things you must respond to.
A cadence
Three releases a year, and for each: thirty minutes on Release Updates as soon as the preview is announced, sixty minutes on filtered notes, and a sandbox test pass for anything in categories one to three above. Write down what you checked, because next release you will not remember whether you already handled something.
Frequently asked
When do the notes come out?
Ahead of each release, with the preview window opening before general availability. Salesforce publishes the schedule, and it is worth putting the dates in a shared calendar rather than rediscovering them.
Do I need to read notes for products I do not own?
No. Filter them out. The platform and API sections apply to nearly everyone. The cloud-specific ones do not.
What is the difference between a Release Update and a critical update?
Release Updates is the current mechanism and the naming has changed over the years. What matters is the page in your org and the enforcement dates on it.
Can I delay a release?
No. Production orgs are upgraded on Salesforce’s schedule. What you can control is testing on a preview sandbox beforehand.
How do I know if a change affects my org specifically?
Release Updates is org-specific. For the rest, the honest answer is that you map it against your own inventory, which is an argument for having an inventory of automations, integrations and API versions before release season.
Reference: Salesforce Release Notes, Release Updates and Sandbox Preview Instructions, Salesforce.
