Welcome back to another post designed to help you prepare for an upcoming Salesforce release. This time, we’re turning our attention to the Summer ’26 Release.
Salesforce uses release updates to provide notice of any behavior changes that will take effect from Summer ’26 onwards. By being a proactive Salesforce Admin, you can prepare ahead of the May enforcement deadline. Failing to do so may leave you in firefighting mode if these changes impact your customisations.
Preparation
When preparing for these updates, a good rule of thumb is to consider two approaches: a clicks-not-code (no-code) or a pro-code approach.
If you have a developer-leaning skill set, SFDX (Salesforce Developer Experience) can give you a head start. These tools allow you to create a local copy of your Salesforce metadata, making it easier to search for and identify impacted references.
You can also leverage third-party tools like Workbench or Salesforce Inspector Reloaded to run queries and uncover references.
Finally, be aware that Salesforce frequently adjusts release updates, sometimes delaying them to a later release, changing their scope or impact, or canceling them altogether. To stay current, always refer to the latest release notes.
Salesforce Summer ‘26 Release
The Summer ’26 release will introduce several mandatory updates. Salesforce flags these changes in advance in the release notes for the prior release. For example, Spring ’26 provides early visibility into what will be enforced in Summer ’26.
This article aims to break down updates in plain English, helping you understand whether they’re likely to impact your org and how to prepare for and test ahead of the enforcement date.
The guidance here outlines general preparation steps and assumes impacted features are being used as intended, without customization. If your implementation uses these features in a bespoke way or includes customizations, you may need to take additional steps beyond what’s described in this guide.
If you use managed packages, some configuration may be owned by the provider and not visible within your org. If you believe a package could be impacted, contact the provider to confirm their readiness.
As with any Salesforce change, start by testing in your sandbox environments and deploy the required updates through each test environment before making changes in Production.
When applying changes to production, schedule them outside of core business hours and allow sufficient time for validation and rollback in case any issues arise.
Enabling Accessibility Enhancements
Two new enhancements were introduced in the recent release updates:
- Enable accessibility enhancements for page headers and modal windows when zoom is greater than 200%
- Enable accessibility enhancements for date pickers, popovers, bottom utility bars, and record headers
These updates are grouped together because their impact and test steps are similar. Depending on the level of customization in your org, the exact steps a developer will need to take to resolve any issues may vary.
If any users access Salesforce at 200% browser magnification or higher, this update may affect the styling of page layouts. Users working at lower magnification levels are not impacted.
This is a browser-level setting, typically adjusted using these keyboard shortcuts:
| Windows | Mac | |
|---|---|---|
| Zoom In | Ctrl + + | Cmd + + |
| Zoom Out | Ctrl + – | Cmd + – |
| Reset to 100% | Ctrl + 0 | Cmd + 0 |
To determine whether your users are affected, consider reaching out via a Chatter poll, Slack post, or in-app guidance message.
Preparing in a Sandbox
In the safety of a Sandbox, enable the test run for this update.
Once enabled, review all page layouts, Visualforce pages, and Lightning pages. During testing, verify that there are no new issues when pages are viewed at 200% zoom across any screen width or at 400% zoom on a 1280px width.
If any custom components are affected, work with a Salesforce Developer to make the necessary adjustments to ensure compatibility with the update.
After changes are made, retest all impacted functionality to confirm everything behaves as expected before planning deployment to other environments.
Preparing in Production
Once you’ve completed testing in your sandboxes and applied any required fixes, prepare to deploy the update to Production.
Schedule the deployment outside of core business hours, and allow sufficient time to enable the test run and perform post-deployment testing. Taking this approach gives you a safety window to identify and roll back any issues before end users are impacted.
Salesforce-Managed X (Formerly Twitter) Authentication Provider Retirement
Salesforce is retiring the X (formerly Twitter) authentication provider. If you currently rely on this provider, authentication will stop working once the change is enforced.
This update does not affect the X Ads for Marketing Intelligence Connector used with Data 360 (formerly Data Cloud).
To check whether you’re using a Salesforce-managed X connector, follow the no-code or pro-code steps.
| No-Code | Pro-Code |
|---|---|
| 1. Navigate to Setup → Auth Providers and review where Type = Twitter. 2. If the consumer key and secret are blank, then you are impacted. | If you see results from the query below, then you are impacted by this release update: SELECT FriendlyName FROM AuthProvider WHERE ProviderType = 'Twitter' AND ConsumerKey = null AND OptionsIsEmi = false |
Preparing in a Sandbox
If you’re impacted, prepare for this change in your Sandboxes first. Updates are required in both X and Salesforce, so you’ll need admin access to both platforms.
In the X Developer Portal, create a new app and make a note of the API Key and API Secret.
In Salesforce, update your Authentication Provider (Auth Provider). For each impacted Auth Provider, set the Consumer Key to the API Key and the Consumer Secret to the API Secret.
Make a note of the callback URL, as this must be added to the X app. If the auth provider is used for Salesforce users, use the standard Salesforce callback URL. If it’s used with Experience Cloud, use the callback URLs from that section instead.
Return to the X Developer Portal and configure user authentication for the app by setting the callback URL to the same callback URI. You can ignore the X client ID and client secret, as they are not required.
Once these updates are complete, verify that test users can still sign in to X as before using the auth provider.
If you have multiple auth providers, consider creating a separate X app per auth provider. You may also want to use a separate app per Salesforce environment to simplify management and troubleshooting.
Preparing in Production?
Choose a time window when the majority of your users are offline to carry out the update. Follow the same steps you used in your sandbox environments to switch each impacted authenticator provider to the nominated app in the X Developer Portal.
Be sure to allow sufficient time for testing so you can roll back the changes if anything doesn’t go as planned.
Use Visualforce PDF Rendering Service With Apex Blob.toPdf()
Salesforce is updating Apex Blob.toPdf() to bring it in line with the equivalent Visualforce service.
The Visualforce service includes enhancements such as additional font support and improved handling of multi-character text, which aligns Apex with these capabilities.
To determine whether your org is impacted, follow the no-code and pro-code steps below:
| No-Code | Pro-Code |
|---|---|
Search your Apex Classes for: Blob.toPdf( | |
Preparing in a Sandbox
Once you’ve identified each impacted function, run it and capture the output so you have a baseline from before the release update was enabled.
Next, enable the test run of the update and run each function again, comparing the results with the pre-update test. If you identify any regressions, work with a Salesforce Developer to make the necessary adjustments.
After completing testing in your initial sandbox, progress the changes through the rest of your sandbox pipeline, including deploying any refactored code required to address the issues found.
Don’t forget to make sure your Apex has sufficient coverage – otherwise, this would block your deployment to Production.
Preparing in Production
Plan to deploy changes at a time that minimizes disruption to users, which is typically outside of core business hours.
Once any required code changes have been deployed and the necessary Apex tests have been run, enable the test run and review each impacted area of the system to confirm that the output aligns with your expectations.
Release Update Changes
If you see the Migrate to a Multiple-Configuration SAML Framework (release update) your org is using the original SAML framework, which Salesforce will upgrade as part of the Summer ‘26 Release. This release update was rescheduled from previous releases and was covered in Salesforce Summer ‘24 Release: What to Expect and How to Prepare.
Update Instanced URLs in API Traffic (Release Update) was covered in Salesforce Spring ‘26 Release: What to Expect and How to Prepare. Salesforce now enforces this with Summer ‘26.
You’d be right to think you’d seen the Sort Apex Batch Action Results by Request Order (Release Update) before. This was covered in the Salesforce Spring ‘25 Release: What to Expect and How to Prepare, and will now be enforced in Summer ‘26.
At this stage, the Adopt the ICU Locale Formats (release update) has been doing the rounds for some time. The latest on this one is that Salesforce is no longer planning to enforce this change, although the release update may still show Summer ‘26 as the enforcement date. Salesforce advises enabling this update and provides a guide here.
This was covered in Salesforce Spring ‘25 Release: What to Expect and How to Prepare. The enforcement of Enforcing No-Argument Constructor on Apex Classes Used for Invocable Action Parameters (Release Update) has been cancelled, but Salesforce recommends this update should be enabled manually nonetheless.
Refer to Salesforce Winter ‘26 Release: What to Expect and How to Prepare for more info.
Final Thoughts
In today’s environment, it’s best to prepare for release updates ahead of time to avoid ad hoc firefighting if an update breaks customizations and disrupts users.
By building a habit of early preparation, you reduce risk and save time if a release update is postponed, shifting your approach from reactive troubleshooting to proactive preparation for what’s to come.
