Salesforce Winter '27 Release Updates: The Breaking Changes That Could Disrupt Your Org

Most of a Salesforce release is safe to be excited about. The part that can hurt you is the enforcements, the changes that are not optional and that can quietly break things you depend on. The Salesforce Winter '27 breaking changes are worth understanding in detail, because a couple of them can disrupt integrations and data access if you are not ready. This guide walks through the ones that matter and how to stay ahead of them.

Here are the Salesforce Winter '27 breaking changes most likely to disrupt an org, and what to do about each.

The Quiet One: Authentication Retirements

The most dangerous Salesforce Winter '27 breaking changes are the authentication retirements, because they can fail silently. The retirement of the OAuth 2.0 username-password flow is the headline: any integration that authenticates by posting a username, password and security token can stop receiving access and simply stop working, with no obvious error. The enforcement timing has shifted, currently pointing to early 2027, but the fix is the same either way, find every integration using the old flow and move it to a supported method now.

Alongside it, the rules around the OAuth device flow are being tightened and email verification handling is changing, both with enforcement dates in late 2026. The practical response to these Salesforce Winter '27 breaking changes is a full audit of how every integration and connected app authenticates, well before the dates arrive.

Finding and fixing these is genuine technical work, the kind covered by our Salesforce Development & Customization service. A silently broken integration is the worst kind, because you often discover it only when the bad data has already spread.

The One That Changes Data Access

The other Salesforce Winter '27 breaking change to watch is Enable Profile Filtering, which is the release enforcement that actually changes what data a user can access. That makes it different from a cosmetic update: if you do not test it, users could see more or less than you intend. It belongs at the top of your testing list, checked carefully in a sandbox before the release reaches production.

The Ones That Moved

Part of staying calm about Salesforce Winter '27 breaking changes is knowing what is not actually landing yet. Some enforcements have been rescheduled: the move to update instanced URLs in API traffic, for example, has shifted to a later release, and one email-domain change was cancelled and replaced by a different requirement. The lesson is to work from the current, confirmed enforcement list rather than last quarter's assumptions, because the dates genuinely move.

How to Get Ahead of Them

The method for handling Salesforce Winter '27 breaking changes is the same as for any release, done thoroughly. Preview in a sandbox, work through the confirmed list of enforcing updates, audit your integrations and authentication, test the data-access change, and fix what needs fixing before the dates. What makes the breaking changes different from ordinary features is that ignoring them is not an option, they enforce whether you act or not.

For how to approach a release methodically, our write-up of the Salesforce Summer release features shows the pattern, and the wider direction is in our Salesforce Agentforce & AI Trends 2026 guide. Handling breaking changes well is really just release management taken seriously.

A Note on Custom Code

Breaking changes hit custom code hardest, because bespoke Apex and integrations are exactly what makes assumptions about how the platform behaves. If your org carries a lot of custom development, the Salesforce Winter '27 breaking changes are a good prompt to review it, not just for this release but for how maintainable it is going forward.

Our guide on custom vs out-of-the-box development covers why lean, well-judged customisation weathers releases better than heavy custom code, and why every unnecessary line is a liability when enforcements land.

‍