Winter '27 Hits Production October 9. Here Is How to Get Your Org Ready

Salesforce’s Winter ‘27 release reaches non-preview instances on October 9 and 10, 2026. That is less than two weeks away. If your org is on one of those instances, the upgrade happens over that weekend whether you have looked at the release or not, and on Monday your users will be working in it.

Three releases a year is a steady rhythm, and it is easy to let them blur together. Most releases are uneventful. The ones that cause trouble are almost never the headline features. They are the quiet changes: a security setting that flips on by default, a legacy behavior that goes away, an integration that depended on something Salesforce retired. This post covers where Winter ‘27 stands, the changes we would check first, and how to use the time you have left.

Where the Release Stands Right Now

Sandbox preview started August 28, 2026. Any sandbox that was active on a preview instance by the August 27 cutoff was upgraded to Winter ‘27 on August 28 or 29. Sandboxes created or refreshed after that cutoff landed on non-preview instances, and they stay on Summer ‘26 until the October rollout.

That split matters for how you test. If you have a sandbox on a preview instance, it has been running Winter ‘27 for a month, and it is the best tool you have. If you refreshed your sandboxes in September, they are on the same version as production, and they will not show you anything new until release weekend.

Not every instance upgrades on the same weekend, so do not assume the October 9 date applies to you. Look up your production instance on Trust Status (Setup shows your instance under Company Information) and put the actual maintenance window on your calendar.

Winter ‘27 is API version 68.0. Apex classes and triggers stay bound to the API version they were saved with, so nothing you have built moves to 68.0 on its own.

The Release Updates We Would Check First

Release Updates in Setup lists the upcoming changes Salesforce plans to enforce, so you can test them in a sandbox before enforcement. That makes it the single most useful page for release prep. Filter to the items due soon and read each one. For Winter ‘27, these are the ones we would look at first.

Profile filtering turns on by default. With profile filtering on, users can only see their own profile name unless they are assigned the View All Profiles permission, and Salesforce is enforcing the release update in Winter ‘27. Salesforce Help explains how profile filtering and View All Profiles work. For most users this is invisible. The people it catches are the ones whose jobs involve profiles without being full admins: delegated admins, help desk staff who assist with user setup, and anyone running reports or list views that show profile names. Work out who those people are and assign View All Profiles before the update enforces, not after the first support ticket.

Email change verification exceptions are going away. Some orgs asked Salesforce Support to turn off email change verification, usually so an integration or a bulk user update could change email addresses without every user confirming. Salesforce is ending that. The Maintain Your Email Verification Exception release update is enforced on December 1, 2026, and at that point Salesforce removes the existing domain allowlists that disabled verification. The replacement is an exception you configure yourself on Authorized Email Domains in Setup. If you are not sure whether your org has the old exemption, find out now. The worst time to learn about it is in the middle of a bulk email update in December.

Integrations using the username-password OAuth flow need a new plan. Salesforce is retiring the OAuth 2.0 username-password flow on February 20, 2027, and its Winter ‘27 architect highlights say the user-agent and hybrid user-agent flows retire on the same date. Any integration that still logs in by sending a username and password to the token endpoint will stop working once the retirement takes effect. Salesforce recommends the web server flow with PKCE or the client credentials flow instead. In practice that usually means client credentials for server-to-server integrations and the web server flow for user-facing apps. February is closer than it sounds, and the work takes longer than people expect: you have to find every integration using the flow, and some of them will belong to vendors, not to you.

To find them, start with your list of connected apps and your Login History, work out how each integration user signs in, then match each one to an owner. Middleware, data loaders, reporting tools, and older custom scripts are the usual suspects.

How to Test in the Time You Have

If you have a preview sandbox, use it this week. A focused test plan beats a broad one.

Run all Apex tests. Kick off a full test run in the preview sandbox and compare the results to the same run in production. A test that passes in production and fails in preview is telling you something changed underneath it. Most of the time the cause is a platform change in validation, sharing, or a default setting, not your code, but you want to know before your users do.

Walk through your critical processes by hand. Pick the five or six things your business cannot live without for a day: creating and converting leads, moving an opportunity to Closed Won, the main approval process, the case intake path, whatever it is for your org. Do each one in the preview sandbox as a real user would, with a real user’s profile or permission sets. Admin accounts hide sharing and permission problems.

Trigger your integrations. Scheduled jobs and inbound integrations are where release surprises tend to hide, because nobody is watching them when they fail. If you can point a test instance of an integration at the preview sandbox, do it. If you cannot, at least confirm how each one authenticates, which brings you back to the username-password flow above.

Activate the release updates you plan to accept. Many release updates can be turned on early in a sandbox. Turn them on in preview, run your tests again, and you will know what enforcement will do before Salesforce does it for you.

If you do not have a preview sandbox this time, you are not out of options. Work through Release Updates in production, where you can read every item and test the ones that allow it, and plan for a closer watch on the Monday after the upgrade.

Tell Your Users Before They Notice

Users do not read release notes, and they should not have to. What they need is a short note before release weekend: what is changing for them, if anything, and who to contact if something looks wrong on Monday. Two or three sentences is plenty. If nothing user-facing changes for your org, say that too. It saves your help desk a round of “did Salesforce change something?” tickets.

For the admin team, block time on the Monday after the upgrade. Check scheduled jobs and integration logs first thing, watch for unusual login failures, and keep an eye on your support queue for the first couple of days.

Make It a Habit, Not a Scramble

The orgs that handle releases well do not treat each one as a special event. They keep one sandbox on the preview schedule, refreshing it before each sandbox cutoff. They review Release Updates once a month instead of once a release. And they keep a short list of the processes and integrations that get tested every time.