How to triage a Salesforce release in thirty minutes

Three times a year the release notes arrive, and in most teams the honest response is a bookmark, a good intention, and nothing further until something in production behaves differently on a Monday morning.

Reading them end to end was never the point. Several hundred pages describe a platform used by every industry at every edition, and almost none of it applies to your org. The job is not comprehension. It is producing a short, org-specific action list before the changes reach you, and that is a half-hour job provided the preparation was done once and the reading order is fixed. Who should own the routine is covered in managed services or an in-house admin. This piece is the half hour.

#The preparation that makes thirty minutes possible

The session is short because most of the thinking already happened. The preparation is a single page describing your org, written once and amended in a few minutes whenever something changes. It lists:

• The clouds and licence types actually in use. Not what was bought, but what is switched on and has people in it.
• Managed packages, with the version installed and the vendor's own release cadence. A package several versions behind is the likeliest source of a surprise in any release.
• Every integration, inbound and outbound, with the API version it authenticates and calls against. Most orgs cannot answer this from memory, and it is what decides whether a retirement notice matters to you.
• The two or three custom areas the business would notice within an hour if they stopped. Usually a pricing or approval mechanism, an assignment model, or a portal.
• Anything running close to a platform ceiling, named rather than measured, so a change to that ceiling gets read carefully rather than skimmed.
• The business processes those things sit under, so a technical change becomes one sentence somebody outside the team will understand.

Written once, that page turns filtering from a memory exercise into a mechanical comparison. Without it the half hour becomes ninety minutes of trying to recall whether anybody still uses a thing, which is the real reason most attempts at a quick triage stop after the second release rather than the tenth.

#Filtering is where the saving actually is

The largest saving here is not reading faster. It is reading almost none of it.

Salesforce publishes one set of notes for the whole platform. If you do not run Field Service, every page of Field Service is noise, and the same goes for clouds you do not license, industries you are not in, and features requiring an edition above yours. Filter first and the document collapses to a fraction of its length. Only then is a careful read affordable.

Two mechanisms do most of that. The notes carry filters for edition, cloud and feature area, and those belong at the start of the session rather than partway through. Then there is the Release Updates page in your own Setup, listing what applies to your org specifically with the dates attached. Shorter, more relevant and more urgent than the notes, it is the correct entry point; the notes become reference material for the items on it.

The habit to resist is reading for interest. A feature that sounds impressive but touches nothing you run costs the same attention as one that will break an integration.

#The four buckets, and the question that sorts each one

Everything surviving the filter lands in one of four buckets. The point of having exactly four is that sorting stops being a judgement call and becomes a question with a yes or no answer.

The fourth bucket does more work than people expect. Deferred is not ignored: it is a decision with the reason attached. When somebody asks in eight months why the org is not using a feature, the answer already exists. It also stops the same item being reconsidered from scratch at every release, which is a surprisingly large share of what an unstructured triage consumes.

#Why enabled by default is triaged first

Platform changes arrive in three forms, and the difference matters more than the subject matter. Some are opt-in, and deferring those costs nothing. Some are switched on with a control to turn them off, and deferring those costs a conversation later. Some apply on a stated date regardless of whether anybody read the note, and deferring one of those buys an incident on a date somebody else chose.

That third group is the whole reason the session exists. It holds release updates approaching enforcement, retirements of API versions and features, and security changes that tighten a default, particularly around what an unauthenticated or guest user can reach. Each is correct as a platform decision and disruptive as a local one, because your org was built while the old behaviour was still true.

Two practical notes. Enforcement dates move, sometimes more than once, so read the date currently stated rather than the one you wrote down last time. And where a release update offers a way to test the new behaviour before enforcement, take it: it tells you what will happen in your org rather than what happens in general, which is the cheapest evidence in the procedure.

#Spotting what will break rather than what will help

This is the skill separating a useful triage from a reading exercise. Improvements announce themselves, because the notes are written to make them findable. Breakages come in the neutral register of a specification, usually as a single clause inside a paragraph about something else.

Phrasings worth slowing down for, all of which mean today's behaviour is not tomorrow's:

• Anything of the form now returns, no longer includes, is now required, or defaults to.
• A change to what an older API version does. Check the version each integration authenticates with, which is often years behind the version your team writes new code against.
• Changes to what an unauthenticated or guest user can reach. These tighten, which is right, and they break public forms and sites built when the rules were looser.
• Anything altering the order or timing of automation on save, because an org's behaviour there rests on assumptions nobody wrote down.
• A managed package vendor's own compatibility statement. Salesforce will not tell you that a vendor's package is unsupported on the new release. The vendor will, in a separate document, and that read belongs inside this session.

The test is the same every time, and it comes back to the org page: does this touch something on the list? If it does, it has stopped being a reading item. It is a sandbox item.

#The half hour, on the clock

One rule holds the whole thing together: the session has to produce written output. A triage ending in an understanding and no list has produced nothing, because the understanding will have faded by the time the release lands.

#The preview window, and what to do in it

Sandboxes on a preview instance are upgraded ahead of production, giving you a window in which your configuration runs on the new release while your live org does not. It depends on one easily missed act of preparation: the sandbox has to be created or refreshed before the preview cut-off. Refresh after that date and you get the current release rather than the next one, and the window is gone until next time. Put the cut-off in a calendar rather than in an intention. Which instance a sandbox sits on, and what that means for preview, is in the Salesforce documentation on sandbox environments.

The window is not for regression testing. It is a targeted check of the paths where a break costs most, aimed by the breakage bucket and the org page:

1. The primary revenue process end to end, including approvals and anything that generates a document.
2. The primary service process, from inbound contact through to resolution, including routing.
3. Every integration, one record in each direction, checked at the far end rather than only at yours.
4. Any managed package not upgraded recently, exercised through its main flow rather than merely opened.
5. The reports and the dashboard leadership actually reads, compared against figures captured before the upgrade.

That last comparison earns its extra ten minutes. A report that runs is not a report that is right, and a quietly changed number is the failure mode nobody catches until it is on a slide in front of the board.

Half a day of this catches the overwhelming majority of release-related incidents. The full regression attempt teams reach for when they have no triage usually runs out of time before reaching the things that mattered.

#What to say, to whom, and what nobody needs to hear

Most release communication fails by being a summary of the release. Nobody outside the team wants that, and sending it teaches people to ignore the next one. Three audiences, three different messages.

The people whose work changes. One paragraph in their language about what will look different and when, not the feature name. If nothing they touch changes, they hear nothing, and that silence is what makes the next message credible.

The people who own something you tested. Integration owners, the vendor contact for a managed package, whoever runs the finance process behind a report. They get the specific sandbox finding before the upgrade rather than after it.

Whoever is accountable for the org. Four lines: what is enforced and when, what you tested, what broke, and what you deferred. A status message, not a document.

Nobody needs the list of new features you decided not to pursue. That is the deferred bucket, and it belongs in your record rather than in anybody's inbox.

#The deferred list is an asset, not an archive

Open the deferred list at the start of the next triage, before anything else. An item deferred as optional last time may now be approaching enforcement, and it arrives already understood rather than as a fresh problem. A feature deferred as immature is often complete a release or two later, and the second look is far quicker because the reason for deferring is written down. And something you built yourself may have been superseded by a platform feature, which is where you notice you are maintaining what the platform now provides.

That last one is where triage stops being purely defensive. Whether accumulated custom work still earns its keep is a wider question, and the method is in a technical debt audit you can run on your own org. Triage feeds that audit with the one input it cannot generate for itself: a current list of what the platform has made unnecessary.

#When thirty minutes stops being enough

The promise in the title holds for a single-cloud org with a handful of integrations and one admin. It stops holding at a point worth naming, because quietly running over is how a routine gets abandoned. Thirty minutes stops being enough once the org page runs past a page: several clouds, packages from multiple vendors, more integrations than one person maintains, or a regulated environment where a change has to be assessed against a control rather than only against a process.

The wrong response is to read faster. The right response is to split the work rather than extend the session, and to say out loud what is being cut.

Split by cloud, not by time. Each cloud has an owner who runs the same thirty minutes against their own section of the org page. What follows is a short merge of four lists rather than one longer read.

In a regulated org, add a fixed step rather than a longer read. Every item in the enabled-by-default bucket is checked against the controls it could touch: access, audit trail, data residency, retention. Roughly a quarter of an hour, and it belongs to whoever owns the control rather than to the admin.

Cut the evaluate bucket first. New capability keeps. Enforcements do not. If the session is going to overrun, drop the third bucket and record that you dropped it, so the next session starts there.

Never cut the first five minutes or the last three. The Release Updates page, and writing the list down. Everything else degrades gracefully under time pressure. Those two do not: without the first you are reading the wrong document, and without the last you have read nothing.

Anything still not fitting after those adjustments is telling you something about capacity rather than about release notes, and that belongs in a conversation about the operating model rather than in the half hour.

#Make it a routine rather than an effort

Three sessions a year, half an hour each, plus half a day in a preview sandbox per release. Its value comes from being repeated rather than from being done impressively once.

The reason it usually does not happen is not cost. It is that the preparation was never done, so every attempt starts from nothing and takes three times as long as it should, and a routine that hurts is a routine that stops. Write the org page first and the half hour follows from it. For the platform's own account of the release cycle and the preview mechanics, the Prepare for Salesforce Releases trail goes deeper than this procedure needs.