You’d be right to think that the Summer ‘25 Release has only just been and gone. With three major updates each year, Salesforce likes to keep us on our toes – and it’s now time to prepare for the Winter ‘26 Release.
If you fail to prepare, features or functionality may break when the release is rolled out to orgs. That’s why it’s important to be proactive rather than reactive. This batch of release updates is due to be actioned by September 2025.
Preparation
Release updates should be enabled in a sandbox first so you can test any impacts on your systems or ways of working.
If you have a developer-type skillset, you can use SFDX tools to search your Salesforce metadata for references that could be impacted by this update and use tools such as Salesforce Inspector Reloaded or Workbench to query records or permissions.
Salesforce may sometimes delay enforcement of a release update or cancel it altogether. Be sure to check the release notes for the latest changes, as things can change or shift around!
Salesforce Winter ‘26 Release
When the Winter ‘26 Release arrives in your Salesforce org, a number of release updates will be auto-enabled. These updates can change behaviour, so be sure to test changes ahead of time so that you can make any necessary adjustments.
This article will provide generic steps on how to prepare your org for the updates. These are provided as a guideline, so there could be additional steps or actions if your org is customized.
If you have any managed packages, then functionality within could also be impacted by the changes. If you suspect this may be the case, then reach out to the provider to check.
When making changes, be sure to complete them initially in your sandbox environments, thoroughly test them, and then deploy onwards to your Production org. Usually, you’d have a number of sandboxes before your live system, so rinse and repeat the process for each environment.
When it comes to deploying changes to a Production system, plan this outside of core working hours and allocate time for testing, so that you can revert changes before users are impacted.
Confirm Verified Email Addresses for Users Created in 2016 and Earlier
What Does This Impact?
If you have users created on or before November 1, 2016, then they could be impacted by this update. Once enforced, users require a verified email address to send emails from Salesforce. If their email address is not verified, then users can no longer send emails.
No Code:
- Create a list view of users created before or on November 1, 2016 where the email is unverified.
- Filter by:
- Created Date <= November 1, 2016
- User Verified Email = False
- Active = True
- Add in Created Date and User Verified Email under “Selected Fields to Display” to get a complete view.
Pro Code:
- Run the following query:
SELECT Id, User.Name, User.Email, User.LastLoginDate, User.CreatedDate, HasUserVerifiedEmailAddress FROM TwoFactorMethodsInfo where User.IsActive = true and HasUserVerifiedEmailAddress = false and user.CreatedDate <= 2016-11-02T00:00:00Z
How Can I Prepare in a Sandbox?
Use the list view or a SOQL query to identify impacted users. If results are returned, those users are actively using the sandbox and need to send emails. Proceed to send an email verification link to each impacted user. To do this, navigate to their user record and click “[Verify]” next to the email address.
Verification links expire after 72 hours, so check in every couple of days using your list view or query to see if users have completed the verification.
Alternatively, you can set up a DKIM key for your email domain. For more information, refer to Authorize a Domain for Return Email Verification.
How Can I Prepare in Production?
Use either the No-Code or Pro-Code method to find impacted users. If results are returned, navigate to each user record and press “Verify” next to the email field.
Check the status every 72 hours to ensure users have completed the action in time for the update enforcement.
Enable Secure Roles Behavior and Update Sharing Group References in Production
What Does This Impact?
You may remember from a previous release that Salesforce made changes regarding roles and sharing group references, but only in sandbox environments.
Starting with Winter ‘26, the same updates will need to be applied in Production instances for things to continue working as expected.
If you have references to “Roles and Subordinates,” you’ll need to update these to “Role and Internal Subordinates” for the impacted functionality to continue running as expected.
No Code and Pro Code:
- Search for references to:
- Roles and Subordinates
- roleAndSubordinates
- RoleAndSubordinates
- roleAndSubordinate
- References could appear in SOQL queries, Apex, flows, components, API integrations, and other metadata.
How Can I Prepare in a Sandbox?
Salesforce enforced the change in behavior in the Summer ‘25 Release for sandboxes, so it’s likely you’ve already updated your sandboxes for the new behavior.
You’ll need to deploy these changes to your Production environment. Before doing so, make sure there aren’t any references that won’t be updated by your deployment, in case the Production and sandbox environments are out of sync.
If things are out of sync, create a new sandbox or refresh an existing one to update references in a test environment first, before deploying all related changes to Production. When refreshing a sandbox, be sure to back up any changes that aren’t deployed elsewhere to avoid losing this work!
How Can I Prepare in Production?
Prepare to deploy any changes from sandboxes within a deployment window outside of core working hours. Deploy changes to production, enable the test run, and then retest the impacted functionality. This way, if issues are found, there is time to roll back the changes and disable the test run with minimal impact on users.
Restrict User Access to Run Flows
This update was covered in the Salesforce Winter ‘25 Release: What to Expect and How to Prepare article. Please review the “Restrict User Access to Run Flows” section to learn how to prepare if you haven’t already made the switch in all your environments.
Update Permissions for Agentforce Service Assistant Users
What Does This Impact?
Salesforce is adjusting the permission required for users who access Agentforce Service Assistant. Currently, it is accessible to those with a Salesforce license, but will be removed when this update is enforced.
Make sure any users who need to continue using this functionality are assigned the Service Planner User Permission Set License before this update is enforced.
No Code and Pro Code:
- Set up Service Assistant Metrics to understand who is using this feature and how it is being used.
How Can I Prepare in a Sandbox and Production?
Assign the Service Planner User Permission Set License to users who currently use Service Assistant.
Other Changes
The update formerly known as “Enforce Permission Requirements Defined on Built-In Apex Classes Used as Inputs” has been renamed to “Enforcing No-Argument Constructor on Apex Classes Used for Invocable Action Parameters”. Salesforce has postponed enforcement of this update until the Summer ‘26 release.
Salesforce was planning to retire the Frequency and Frequency Type fields on the Maintenance Plan object in Field Service. This has been canceled, and so the related release update, “Migrate from Maintenance Plan Frequency Fields to Maintenance Work Rules” has also been canceled.
Summary
By planning ahead for the upcoming changes, you can prioritize them against other changes to ensure your systems are updated in time. Stay tuned for more content on the Winter ‘26 Release.
