How to triage a Salesforce release in thirty minutes

Three times a year the release notes land, and the honest response in most teams is a bookmark, a good intention, and nothing else until something changes unexpectedly in production.

Reading them cover to cover is not realistic and was never the point. The goal is a short, org-specific action list. Here is the reading order we use, and it fits in half an hour.

#Minutes 0-10: retirements, enforcements and things with dates

Start here, always. Everything else in the release is optional; this section is not.

You are looking for three categories:

• Release updates being enforced. These have an activation deadline and they will apply whether or not anyone read the note. This is the single highest-value part of the document.
• Retirements and end-of-life notices. API versions, features, integrations. These matter most if you have old integrations pinned to old API versions, which almost everyone does.
• Security changes that alter default behaviour. Anything that tightens access or changes what an unauthenticated or guest user can do.

For each item, ask one question: does this touch anything we run? If yes, it goes straight on the act-now list with the deadline written next to it.

#Minutes 10-20: filter to what you actually run

Now go to the feature sections, and read only the ones matching what is live in your org. If you do not use Field Service, skip Field Service. Interesting is not the same as relevant.

Within each relevant section, prioritise in this order:

1. Changes to existing behaviour: anything that alters how something already works. This is where surprises come from.
2. Limit and governor changes: up or down. Both matter if you run anything near a ceiling.
3. Genuinely new capability, the fun part, and the least urgent. Note it, do not chase it.

The single most useful habit here is keeping a one-page list of what your org actually uses: clouds, key packages, integrations, and the two or three custom areas that are business-critical. Written once, it makes this step mechanical rather than a memory exercise.

#Minutes 20-30: write three lists

Do not finish the reading session without producing output, or the whole thing evaporates.

The third list is the one people skip and the one that pays off. Six months later, when somebody asks why you are not using a feature, "we assessed it in the March release and it does not fit because X" is a much better answer than starting the evaluation from scratch.

#The afternoon in the preview sandbox

Thirty minutes of reading tells you what to test. A preview sandbox, refreshed before the preview cut-off, which is the part teams miss, tells you what actually breaks.

Do not attempt full regression. Target the five paths where a break would be most expensive. In most orgs that is:

1. The primary sales process end to end, create through to closed won, including approvals.
2. The primary service process, inbound case through resolution, including any routing.
3. Every inbound and outbound integration, one record each, checked at both ends.
4. Anything using a managed package that has not been upgraded recently.
5. Your three most-used reports and any dashboard leadership looks at.

That is an afternoon of work and it catches the overwhelming majority of release-related incidents.

#Make it a habit, not a heroic effort

Three sessions a year, thirty minutes each, plus one afternoon of targeted sandbox testing per release. Roughly a day and a half annually.

Compare that to a single unexpected production incident caused by a change that was documented months earlier, and the trade is obvious. The reason it does not happen is not cost, it is that nobody owns it.

So the last step is the only one that really matters: put a name and a calendar entry against it. Release readiness that belongs to everybody belongs to nobody, and the release notes will keep arriving regardless.