Your nightly sync into the accounting system stopped running on a Tuesday. Nobody found out until the month-end close nine days later, when finance asked why half the invoices were missing. There was no error message, no red banner in Salesforce, no failed-job email. The integration asked for an access token, was refused, and stopped.
That is the shape of the Salesforce Winter '27 breaking changes. They are not features you evaluate and decide to adopt. They are Release Updates, which Salesforce switches on for you on a published date, and the three that matter most this autumn all fail quietly rather than loudly. Production orgs are being upgraded across September and October 2026.
What a Release Update is, and why you can't opt out
Salesforce ships three releases a year. Most of what arrives is optional - new screens and settings you can ignore until you have time. A Release Update is different. It is a change to how the platform behaves that Salesforce activates on a fixed date whether or not anyone at your company has looked at it. You can usually switch it on early to test. You cannot switch it off permanently.
No edition or licence exempts you. Release Updates are not tiered and they do not cost extra: a Professional Edition org and an Unlimited Edition org get the same enforcement on the same schedule. That is worth stating plainly, because most release coverage is about capabilities you have to pay more to use. This is the opposite - a change you are getting whether you asked for it or not.
You can see your own list at any time. In Setup, search for Release Updates. Every item there carries the date it becomes mandatory for your org, which is the only date that actually matters.
The three Salesforce Winter '27 breaking changes that fail silently
1. Profile filtering gets switched on. A profile in Salesforce is the record that controls what a user can see and do. Until now, any user could read the profile names of other users. From Winter '27 they see only their own, unless they hold the View All Profiles permission. Salesforce's release note for this update is direct about the fix: assign that permission to the people who need it before the update is enforced. It was optional in Summer '26 and is enforced in Winter '27.
The quiet part is what happens to automation. An approval route that branches on the approver's profile, or a validation rule that checks the record owner's profile, does not throw an error when the name is hidden. It reads a blank and carries on to the next step.
2. SOAP API logins need a named permission. The Winter '27 notes include a Release Update titled "Assign Use Any API Auth Permission for SOAP login()". Older integrations that log in through the SOAP API will need their integration user to hold that permission. Integration users are usually provisioned on deliberately stripped-down profiles for security reasons, which makes them exactly the accounts least likely to have it already.
3. The username-password login flow for connected apps is being retired. A connected app is the record that lets an outside system talk to your Salesforce. The oldest way for one to authenticate is to post a username and password and receive a token back. Salesforce is retiring that flow. The retirement sits in the Winter '27 release notes, but the enforcement date has already moved and is currently reported as 20 February 2027 rather than your October upgrade weekend. Do not take that date from a blog post, including this one. Read the date shown against the update in your own Setup.
The two supported replacements are the client credentials flow, where the connected app runs as one designated integration user and authenticates with a key and secret, and the JWT bearer flow, which uses a signed certificate. Both remove the stored password from the integration entirely, which is the point.
What this actually costs a 60-person business
Picture a company of sixty people running Sales Cloud. Salesforce is wired to the accounting system for a nightly invoice sync, to a dialer for the inside sales team, to the lead form on the website, and to a reporting tool that pulls a weekly extract. Four connections, built across four years by two outside vendors and one employee who has since left.
If the accounting sync stops on the 3rd, finance discovers it at the close on the 30th and rebuilds the month by hand. Annoying, recoverable, maybe two days of somebody's time.
The lead form is the expensive one. If it stops creating records, there is no failed record to find later. You cannot audit leads that were never written. A three-week gap in a channel that produces even a handful of enquiries a week is revenue you will never be able to quantify, let alone recover, and nobody will raise it because the website form keeps showing a thank-you page.
Profile filtering fails in a subtler way. An approval process that routes discounts above a threshold to a second approver, based on the first approver's profile, stops branching correctly. Nothing errors. Discounts get approved that should have gone up a level, and the finding arrives months later in a margin review, at which point the conversation is about a quarter of pricing decisions rather than a configuration setting.
In all three cases the platform is doing exactly what it was told. The gap is between the change Salesforce made and the twelve small assumptions built into your org by people who are no longer available to ask.
The catch: nobody has a list of what is connected
The fixes themselves are small. Assign a permission. Reconfigure a connected app to use client credentials. Add a permission set to an integration user. A competent admin does any one of these in well under an hour, and none of them requires a project.
The inventory is the real work. Most companies at this size cannot answer the question "what is connected to our Salesforce, and how does each one log in?" Connected apps accumulate the way browser extensions do: a trial somebody ran in 2023, a middleware account created by a vendor who has moved on, a script running on a finance laptop under a shared login. Every one of them is a candidate for silent failure, and the list is not sitting in a document anywhere.
There is a timing catch too. Testing a Release Update before it reaches production means having a sandbox that was refreshed before the preview cutoff, which passed in late August this cycle. Teams that missed it are not testing in advance; they are verifying afterwards, on live data.
And dates move. At least two items in this group have been postponed at least once. That looks like breathing room, and it is precisely why a team that read the release notes in August has stopped thinking about them in September. Postponement is not cancellation - it usually just means the failure lands in a quarter when nobody is watching for it.
Working out which of your integrations still authenticate with a password, and which automations read someone else's profile, is a couple of hours of investigation by someone who knows where to look. It is worth doing before it turns into an unplanned weekend.
Get a second pair of eyes before your upgrade weekend
Most orgs on the October rollout waves still have a few weeks. DuCodes offers a free 30-minute Salesforce readiness review: we look at your connected apps, your integration users and your automation, and send you a one-page list of what will break, what to assign, and what you can safely ignore. No preparation needed from your side beyond read access for one call. Book a review and put a date next to each item before the release picks one for you.