What to Expect in the Salesforce Winter ’27 Roll Out

Every few months, a new Salesforce release lands in your org whether you’ve prepared for it or not. The Salesforce Winter ’27 Release is no different, and this cycle leans more toward security, authentication, and accessibility than flashy new features, which makes Salesforce upgrade preparation just as important as usual.

That makes it easy to underestimate. A release that doesn’t headline with big new screens can still break an integration, change how a permission behaves, or quietly retire an authentication method your middleware depends on. Here’s what actually matters, and how to get ready before it reaches production.

 

Key Dates to Put on Your Calendar

Salesforce rolls out three major releases a year, and Winter ’27 follows the usual rhythm of pre-release access, published release notes, a sandbox preview window, and staggered production dates.

• Pre-release access: Developer Edition orgs with Winter ’27 features will be available soon so that users can experiment with the new features without impacting their actual data.
• Release notes availability: The complete Salesforce release notes will be available from mid-to-late August, including all aspects of the product family.
• Sandboxes refresh cut-off date: Sandboxes need to be refreshed or created before the given cut-off date in late August to be in the preview environment. Failure to do so results in your sandbox being in the existing release environment.
• Preview of sandboxes: Preview-enabled sandboxes gain Winter ’27 features right after the cut-off, giving several weeks of testing prior to production.
• Upgrade of production orgs: Upgrade of production orgs occurs in waves from September to October, depending upon the instance your organization is in.

Your exact dates depend on your instance. Salesforce Trust lists maintenance windows by instance name, and Company Information in Setup will tell you which instance you’re on if you’re not sure.

 

What This Release Actually Means for Your Org

Winter ’27 is not a release built around one headline feature. It’s a release built around tightening how your org authenticates users, controls data access, and connects to outside systems.

This translates into a series of Salesforce releases updates where administrators no longer have the option of choosing whether to implement them. For businesses, it is largely about keeping everything the way it is today, as long as these updates have been properly reviewed and tested. The problem is not the Salesforce release update. It is when one discovers an affected integration on Monday morning.

 

The Shift from Connected Apps to External Client Apps

One change worth specific attention is the continued move away from Connected Apps toward External Client Apps. Salesforce has been steering orgs in this direction for several releases now, and the Salesforce Winter ’27 release continues that trend.

External Client Apps aim to solve some security issues associated with the previous Connected App model, such as tighter default permissions and cleaner separation between admin and developer configurations. While Connected Apps continue to function as they were, the creation of new apps is more oriented towards the External Client App model, which has a migration option provided by Salesforce itself through App Manager.

If your organization has integrations, middleware, or third-party tools authenticating into Salesforce, this is worth a direct look. Some authentication flows, particularly older username-password based connections, are not supported the same way under External Client Apps. An integration that has quietly worked for years is exactly the kind of thing that fails without warning if nobody checks it first.

 

Other Release Updates Worth Reviewing

Beyond the Connected App changes, Winter ’27 includes a handful of release updates that affect authentication, permissions, and how certain data is visible to users. Exact scope varies by org, so the right move is to open Release Updates in Setup and review what applies to your environment specifically, rather than assume none of it does.

There are a few categories which typically require special attention, including:

• Changes to authentication which affect how integrations and third-party applications login
• Changes to permissions and visibility which may impact user visibility
• Accessibility improvements, which are generally low risk but still worth a quick test
• Email and domain verification requirements for orgs doing bulk email operations

None of these are unusual for a Salesforce release. What matters is treating “release update” as a to-do item, not background noise.

 

Why Sandbox Preview Matters More Than It Sounds

A Salesforce sandbox preview sounds like a technical detail, but it’s the single most useful tool available before a release reaches production. It lets you test the exact version of Salesforce your org is about to receive, using your actual configuration, without any risk to live data or users.

This is further validated by Salesforce’s very own State of IT study that finds most security professionals are finding it increasingly hard to keep pace with change in compliance and regulations. The lack of testing in preview creates this operational risk, and hence it makes sense to close the gap before it becomes an actual risk.

Area to Review	What to Check	Why It Matters
Integrations and middleware	Authentication method, API calls, error handling	Some auth flows are retired or restricted under new security updates
Automations (Flows, Apex triggers)	Whether logic still fires correctly on affected objects	Permission or visibility changes can alter automation behavior
Custom permissions and profiles	Any settings tied to updates enforced this release	Default visibility changes can affect reporting and access
User workflows	Login, common tasks, report access	Confirms the day-to-day experience hasn’t shifted unexpectedly
Connected Apps in use	Authentication type, migration eligibility	Some apps may need to move to the External Client App model

A Practical Pre-Release Checklist

Before your production upgrade weekend arrives, a short structured review goes a long way:

1. Open Release Updates in Setup and note which ones apply to your org.
2. Review the official release notes for the products and clouds you actually use.
3. Confirm your sandbox is on the correct instance to receive the preview.
4. List every integration, middleware connection, and Connected App currently in use.
5. Test critical automations and workflows in the preview sandbox, not just the login screen.

• Flag anything that does not behave normally and assign someone who can make it right before going into production.
• Make users aware of changes that will affect them in advance.

An Example Case

For example, there is a mid-size company using Salesforce and several integrations with it – an ERP integration, a marketing automation platform, and a custom application for sales reps.

A possible way to address this would be to look through the release notes in search of authentication or integration issues and find out how many of those three integrations are still using older authentication approaches. After this, all three will be tested on the preview sandbox, where you find out that the ERP integration uses a deprecated login flow.

The application and marketing tool used by the field team pass the test of cleanliness. Quick validation is carried out to ensure that the reports and dashboards appear the same. There is nothing much in the process of rolling out into production since the real work was done weeks back in the sandbox.

 

Reducing Release-Day Surprises

Most release problems trace back to the same root cause: something wasn’t tested because nobody knew it needed to be. A structured Salesforce release management approach, where org readiness gets reviewed on a fixed schedule each cycle rather than left to chance, removes most of that risk.

 

Conclusion

Organizations with limited in-house Salesforce resources, or integrations too complicated to test on a sandbox, will generally find that this is when their external Salesforce knowledge comes in handy. With the Salesforce winter ’27 release consultants will be able to conduct release readiness assessments, test the integration and automation against the preview environment, identify which connected apps should be migrated, and watch the organization’s performance closely for a few days following go live. This structured approach makes the release cycle a predictable process.

FAQs

When will the Salesforce Winter ’27 Release go live?

Rollout of the production upgrade will take place in phases from late August to October 2026; the exact date varies based on your org’s instance. To know when your instance will upgrade, log into Salesforce Trust.

What should Salesforce administrators prepare before the upgrade?

Begin with checking Release Updates under Setup for your org. You may need to check any of your Connected Apps, integration, and automation that have anything to do with authentication and permission. Testing these on your preview sandbox is the best option.

Why should you test your integrations on a sandbox before the release hits production?

This is because the preview sandbox will be an exact copy of the upcoming Salesforce release going to your org, and therefore you get a chance to identify any integrations, automation, or permission issues without affecting your live org.

What should companies do with the integrations impacted by release updates?

Identify the integrations that use old authentication methods or Connected Apps. Test these on your preview instance and either configure or migrate them before your production upgrade date.

For more insights, updates, and expert tips, follow us on LinkedIn.