Salesforce releases, workflow rule retirement and API version retirements: the admin checklist

Searches for "salesforce workflow retirement" and API version retirement spike every time Salesforce announces a date, which tells you how many orgs find out late. A retainer admin treats releases and retirements as a standing checklist rather than a surprise.

Before each of the three releases

Read the release notes for what is deprecated, not only what is new. Refresh a sandbox on the preview window and run the org's critical paths: lead conversion, quote to order, the integrations, the reports leadership opens on Monday. Upgrade managed packages in the sandbox first. Note anything that changed behaviour and tell the business before the release lands in production.

Workflow rules and process builder

Both are retired in favour of Flow. The checklist is an inventory of every active rule and process, a decision per item (migrate, merge into an existing flow, or retire because nobody remembers why it exists), a sandbox build, and a cutover with the change logged in your org. The hardest part is the inventory, because the rules nobody remembers are the ones that fire.

API version retirements

Integrations pinned to an old API version keep working until the version is retired, then fail with little warning. The admin inventories every connected app and integration user, checks the API version each one calls, and gets the owner to update before the retirement date. Micronetbd published a longer piece on why API version retirement matters to your org; the checklist above is the admin's half of it.

Why this belongs on a retainer

A release checklist is the kind of work an overloaded in-house admin postpones and an outsourced team cannot, because it is on the weekly plan for every client at once. The same named admin runs it for your org, logs what changed, and your users never find out about a release from a broken page.