--- title: "Winter '27: the change that breaks integrations, and two you can take your time over" url: "https://trailassembly.com/winter-27-what-matters/" topic: "Release Coverage" published: "2026-09-11T03:47:11+00:00" updated: "2026-09-23T11:03:48+00:00" --- # Winter '27: the change that breaks integrations, and two you can take your time over **One change in Winter ’27 will break working integrations, and it is not on anybody’s highlight reel.** Salesforce stops supporting the OAuth 2.0 username-password flow for connected apps. If an integration in your org still authenticates that way, it stops working, not degrades, stops. Everything else in this release is something you can adopt on your own schedule. ## 1. The username-password OAuth flow is gone, and it takes integrations with it Salesforce has been discouraging this flow for years, blocking it by default for new orgs and publishing replacement guidance. Winter ’27 is where the discouragement becomes removal: [support for the OAuth 2.0 username-password flow for connected apps ends](https://help.salesforce.com/s/articleView?id=005388592&language=en_US&type=1), and integrations using it break. The flow is the one where a client sends a username and password straight to the token endpoint and gets an access token back. It exists in a lot of orgs because it is the easiest thing to write, and because someone wrote it in 2017 and it never needed touching again. **How to find out whether this is your problem.** Do not go looking through code first — go looking at logins. In Setup, open Login History and filter for the connected apps you know about. Anything authenticating with a username and password rather than a proper OAuth handshake shows up there, including the integrations nobody documented. **What to move to.** Two supported options, and the choice is genuinely easy: - **Client credentials flow** for server-to-server work with no user involved. A nightly ETL job, a middleware connection, an internal service. This is what most broken integrations should become. - **Web server flow** when a real person is authorising access on their own behalf, which is anything user-facing. Budget more time than the change deserves. The code edit is small. Finding every caller, getting credentials reissued, and coordinating with whoever owns the other end is what takes the weeks. ## 2. Sharing recalculation got faster, which is a behaviour change if you depend on timing Salesforce has optimised how [sharing recalculation](https://trailassembly.com/salesforce-data-skew/) runs. Good news for anyone who has watched a role change grind through a large org, and a real change in behaviour for code that assumed share records are updated by the time the next line runs. If you have Apex or a flow that changes ownership, role or group membership and then immediately reads or writes share records, that sequence is the thing to test in a preview sandbox. Automation that was accidentally relying on synchronous recalculation will not throw a clear error. It will read a state that has not caught up yet. This is the class of change that never makes a highlight reel and produces the strangest bug reports. If your org has any of the [ownership skew](https://trailassembly.com/salesforce-data-skew/) we described in [data skew and the 10,000-record line](https://trailassembly.com/salesforce-data-skew/), you are more exposed than most, because your recalculations are the long ones. ## 3. Agentforce Platform is on by default Winter ’27 enables Agentforce Platform by default rather than waiting for an admin to turn it on. “On by default” is worth reading carefully, because it does not mean agents start doing things in your org. It means the platform capability is available, and the governance question moves from “should we enable this” to “who can build with it, and what can they connect it to”. Those are permission and data-access decisions, and they are better made in the week the release lands than in the week after someone builds something. Practical version: review who holds the permissions that let them create and activate agents, and decide deliberately. Enabled and ungoverned is a worse position than disabled. ## The release notes moved things, and it will cost you ten minutes Customisation release notes now sit in a new **Platform** section, alongside Deployment, Development, Experience Cloud, and Mobile and CMS. If you have a saved reading route through the notes (and if you work releases properly, you do) it changed. Not a feature, but knowing it saves you deciding that a section vanished. ## What I would not spend time on yet The AI headline items make a good demo and a poor first week. Nothing in that category will break your org on release weekend, and everything in it will still be there in November when you have time to evaluate it against a real use case. Spend release week on the authentication change and the recalculation behaviour, because those two are the ones with a deadline attached. Adoption decisions do not have deadlines. Enforcement does. ## Getting your own dates Your org’s upgrade date depends on its instance, and the only authoritative source is [Salesforce Trust](https://status.salesforce.com/products/all/maintenances) — open the Maintenances tab and find your instance. Winter ’27 previews landed on preview-track sandboxes in late August 2026, with production instances upgrading across September and October. Two dates matter more than the release weekend itself: the sandbox refresh cutoff, which decides whether you get a preview sandbox at all, and your own production date, which decides how long you have to fix what the preview tells you. Both are on Trust, and both are worth putting in a shared calendar rather than one person’s memory. ## Frequently asked **Can I delay the release?** No. Major releases are not optional and not schedulable. [Release Updates](https://trailassembly.com/release-updates-that-break-things/) inside them can sometimes be activated early or deferred for a window — that is the only lever, and it is a small one. **Will the OAuth change break Data Loader or the CLI?** Those authenticate through supported flows, so no. The risk sits in bespoke integrations, older middleware connections, and scripts written by people who have left. **How do I test the OAuth change before the release?** Set up the replacement flow now, in parallel, in a sandbox. Both can exist at once, which means the migration does not have to be a cutover. You switch the client over once the new credentials work. **Is there a way to see every Release Update being enforced for my org?** Yes, and it is the first thing to do each release: Setup, Quick Find, [Release Updates](https://trailassembly.com/release-updates-that-break-things/). It lists what is enforced, when, and what each one changes. It is org-specific, which is why it beats any blog post including this one. --- Source: https://trailassembly.com/winter-27-what-matters/ Trail Assembly — independent Salesforce write-ups.