The quick version: retirements are the only Salesforce changes with a hard deadline and no opt-out, and they almost always hit integrations rather than users. Below is what is currently retired or dated, what breaks when each one lands, and (the part most lists skip) how to check whether your org is exposed rather than assuming it is not.
Checked against Salesforce documentation in September 2026. Retirement dates move, usually later. Confirm each one against the linked page before you plan work around it.
Authentication
OAuth 2.0 username-password flow for connected apps — support ends in Winter ’27.
The flow that sends a username and password directly to the token endpoint. Salesforce is ending support, and connected app integrations using it stop working rather than degrade.
How to check: Setup, Login History. Look at what your integration users are doing and how they authenticate. The integrations that will break are the ones nobody has touched in years, so search by user rather than by app.
Where to go: client credentials flow for server-to-server, web server flow when a person is authorising. Both can run in parallel with the old flow while you migrate, so this does not need to be a cutover.
APIs
SOAP API login() in versions 31.0 through 64.0, not supported from Summer ’27.
Not the whole API version — the login() call specifically, across that range of versions. Anything that establishes a session by calling login() and then reuses the session Id is in scope, which describes a lot of older middleware and a lot of scripts.
How to check: Login History, filtered on API Type. Entries showing SOAP Enterprise or SOAP Partner are the callers to trace, and the API Version column tells you which version each one used.
Legacy platform API versions 21.0 through 30.0 — retired in Summer ’25.
Already gone. SOAP, REST and Bulk versions in that range were deprecated in Summer ’22, and after two postponements retirement landed in Summer ’25. Versions 7.0 through 20.0 went earlier.
Two lessons in that history worth carrying. Salesforce does postpone retirements, sometimes by years, so a team that panicked in 2023 spent that budget early. And it does eventually happen, so a team that read the postponement as a cancellation is now broken. Plan for the date, expect it to slip, do not treat a slip as a reprieve.
How to check what version your callers use: the API Version column in Login History for SOAP, and your integration’s own configuration for REST endpoint paths, where the version is in the URL.
Behaviour changes worth tracking like retirements
These are not retirements, and they belong on the same calendar because they have the same property: a date, and no opt-out.
Sharing recalculation optimisation. Salesforce has changed how recalculation runs for performance. Code and flows that assumed share records are updated immediately after an ownership, role or group change can read state that has not caught up. There is no error to catch. The values are simply not there yet.
Agentforce Platform enabled by default in Winter ’27. Not a retirement, but a default flipping is the same kind of event: something changes in your org without anybody choosing it. The work is governance, who can build and activate, and against what data.
How to build your own exposure list, once
This is the part that turns a tracker from reading into work. Three sources, in this order:
- Login History. Every authentication attempt, with the user, the API type and the API version. It is the single best inventory of integrations your org actually has, as opposed to the ones it has documentation for.
- Connected Apps in Setup. What exists, who authorised it, and when it was last used. Anything not used in six months is either dead or seasonal, and you need to know which.
- Your own integration register. If you do not have one, Login History plus Connected Apps is how you start it. One row per integration: system, user, auth flow, API version, owner’s name. The owner’s name is the field that matters at 9am on enforcement day.
Do this once, keep it current, and every future retirement announcement becomes a lookup instead of an investigation.
What I would actually do with this list
Sort by whether the deadline is inside your planning horizon, then by whether you know who owns the thing that breaks.
The authentication retirement is the one to act on now, because it is dated, it breaks silently from a user’s point of view, and the migration involves other teams, which means it takes longer than the work suggests.
The API retirements are calendar entries with an inventory task attached: know which callers use which versions, before you need to.
And put one recurring hour in the calendar each release to re-read this and your org’s own Release Updates page. Retirements do not announce themselves twice.
Frequently asked
Does Salesforce warn you before a retirement? Yes, usually years ahead, through release notes, Release Updates and admin emails to whoever is listed. That last part is the weakness: the email goes to an address, not to the person who owns the integration.
Can I request an extension? Occasionally, through support, for a narrow window, with a good reason. It is not a plan.
How do I know if a managed package uses a retired flow or API version? You often cannot from the outside: ask the vendor for a statement in writing, and ask before the release rather than during it.
Is there one official page listing all retirements? Not one that covers everything usefully. Release Updates in your own org is the closest, and it only covers what applies to you, which is the right scope, and also the reason a list like this one exists.
