Salesforce Winter '26 Release: Enforced Updates You Can't Miss

It’s that time again - Winter is rolling in for our northern hemisphere neighbours, and so have the latest Salesforce updates! We’ve dug through the Winter ‘26 release notes and handpicked the most exciting features for business users and admins.

Check out our latest blog, where we break down the highlights and what they mean for you!

The below outlines some important Enforced Updates that may impact your Salesforce instance.

Enforced Updates in Salesforce Winter '26

The following items may impact some clients. For those who are impacted, please check the date by which they will need to be reviewed and rectified. Enrite recommends creating a sandbox to enable the relevant changes and performing the necessary regression tests.

Unverified Email Addresses Can No Longer Send Emails

What’s Changing?
Any user account created on or before 1 November 2016 must have a verified email address to send emails from Salesforce. Accounts created after that date already can’t send emails unless their email address is verified.

What Does This Mean?
To avoid disruption, review your older user accounts and make sure their emails are verified:
Create a list view of users created before 1 November 2016 with unverified emails.
Send verification links to those users so they can continue sending emails from Salesforce.

➡️ For technical details, see this link.

Update References to Legacy Host Names (Automatically Enabled)

What’s Changing?
In Salesforce Winter '26, redirections for legacy (non-enhanced) host names will be disabled in production and demo orgs unless you have chosen to opt out before your Salesforce org receives this release. They were already removed in other orgs during Winter '25. The update is automatically enabled in Winter '26 and permanently enforced in Spring '26.

What Does This Mean?
Any integrations, bookmarks, or processes still using old Salesforce host names may stop working when redirections end. To stay prepared:

1. Identify Legacy Host Name Usage:

• Search for URLs in:
  • Email Templates
  • Bookmarked or shared links
  • Visualforce pages or Lightning components
  • Hard-coded links in integrations or custom code
  • Third-party systems that link to Salesforce
  • Public websites linking to Salesforce (e.g., customer login pages
  • Old domains like:
    • *.salesforce.com (without My domain prefix)
    • login.salesforce.com
    • naXX.salesforce.com

2. Update All URLs to Use Your My Domain

Replace any legacy links with ones that use your My Domain (e.g., mycompany.my.salesforce.com).

➡️ For technical details, see this link.

Restrict Flow Access

What’s Changing?
Starting in Salesforce Winter '26, only users with the appropriate permissions will now be allowed to run flows. The FlowSites org permission, which previously gave all users access to run any flow, is now deprecated with Winter ‘26.

What Does This Mean?
Before, any user could run all flows. Now only users with the Run Flows permission (through a profile or permission set) can run them.

• Assign the "Run Flows" permission via:
• A permission set

➡️ For technical details, see this link.

Enable Secure Roles Behaviour and Update Sharing Group References in Production

What’s Changing?
To better protect your data, Salesforce now limits record access to internal users when you enable digital experiences. The default sharing group name changes from Roles and Subordinates to Roles and Internal Subordinates.

What Does This Mean?
Code or customisations that still reference the old group name can cause errors. To prepare:

1. Audit Your Sharing Configurations:

• Search for any sharing rules, Apex code, Visualforce pages, Lightning components, or Flows that reference:
  • "Roles and Subordinates"

Look especially for:

• Apex sharing logic (Database, SharingRule)
• Custom sharing rules in Setup
• Metadata/config files
• Hard-coded sharing group names

2. Update References to the New Name

• Replace:
  • "Roles and Subordinates" with
  • "Roles and Internal Subordinates

➡️ For technical details, see this link.

Update Instanced URLs in API Traffic

What’s Changing?
Salesforce is retiring the service that allows API traffic to use hard-coded instance names. Going forward, all API traffic must use your org’s My Domain login URL. This approach ensures your integrations keep working if your org moves to a new instance and adds an extra layer of security because each My Domain name is unique.

What Does This Mean?
Salesforce will no longer support API traffic that uses hard-coded instance URLs (for example, na45.salesforce.com). All API integrations must use the My Domain login URL instead (for example, mycompany.my.salesforce.com).

Steps to prepare:

1. Identify API Integrations

• Audit all applications, middleware (e.g. MuleSoft), custom code, and scripts that connect to Salesforce through API.
• Look for any that use hard-coded instance URLs like naXX.salesforce.com

2. Update API Base URLs

• Replace any hard-coded instance URLs with your My Domain URL.
• You can find your My Domain by going to Setup > My Domain in Salesforce.

3. Test All Integrations

• Run tests after updating to confirm that all API integrations work with the My Domain URL.

4. Enable and Validate the Release Update

• Go to:
  • Setup > Quick Find > Release Updates > Find: "Update Instanced URLs in API Traffic"
  • Follow Salesforce's guidance to test and activate the update manually before enforcement.

➡️ For technical details, see this link.

Update Licences for Agentforce Service Assistant Users

What’s Changing?
Starting in Winter '26, access to Service Assistant is no longer included in the standard Salesforce licence. Instead, users need the Service Planner User permission set licence. Permissions for Service Assistant will be removed from the Salesforce licence.

What Does This Mean?
Users who currently access Service Assistant through the Salesforce licence will lose access unless you assign them the new licence. To prepare:

1. Identify Impacted Users

• Find all users who
  • Currently access Agentforce Service Assistant
  • Rely on access granted via the Salesforce Licence
• These users must be migrated to use the new permission set licence.

You can do this by:

• Checking current profiles
• Reviewing permission assignments
• Running a user licence report in Setup or using SOQL

2. Assign the Required Licence

• For each affected user:
  • Assign the Service Planner User permission set licence (PSL)
  • Then assign an appropriate permission set that includes Service Assistant access (if not already included)

Note: Assigning the PSL alone is not enough — you also need to assign permission sets that use that PSL.

➡️ For technical details, see this link.

How to Move Forward?

If you think the Winter '26 release may affect your setup or wish to get ahead, reach out to us as soon as possible. We can review your environment and take action or provide advice to address any issues. To contact us, please raise a ticket in our portal.

Also, consider joining the Release Readiness Trailblazers group for more information, or sign up for the Salesforce Release Readiness Live Webinars to stay updated.