Summer is coming, and with it, the Salesforce Summer ‘25 release! Salesforce introduces new features three times a year, and with each release come release updates that change how certain features behave. Since these updates are automatically enabled by Salesforce, be sure to prepare ahead of time to ensure your functionality continues to work as expected.
The preparation for these updates is due by May 2025, when Salesforce begins turning on these release updates along with the Summer ‘25 updates.
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 Summer ‘25 Release
When Summer ‘25 is rolled out to Salesforce orgs, the release updates mentioned in this article will be enforced. Make sure that you review the list of updates so you are prepared ahead of time to ensure your system continues to run smoothly.
This article will provide general steps to enable these updates. These are provided as guidelines, so additional steps or actions may be applicable to your orgs.
If you have any managed packages installed that you suspect could be impacted by these updates, reach out to the provider to ensure those packages are ready.
When planning changes in a production environment, make them outside of working hours so they can be tested while users and customers are offline. If there are issues, this allows you to revert any changes before they impact users or clients.
Enable a Modernized Record Experience in Aura Sites
What does this impact?
If you are using Experience Cloud, then this change will impact Aura sites.
Salesforce is updating the look and feel of the Create Record Form, Record Banner, and Record Detail components. Salesforce recommends you test all customized record components before this update is enforced.
No Code and Pro Code:
- Navigate to Setup → Digital Experiences → All Sites.
- Review sites where Framework equals Aura.
Note: If you only see Salesforce CMS and Settings under Digital Experiences, it means Experience Cloud is not enabled.
How can I prepare in a sandbox?
Once you’ve identified impacted sites, review your sites to understand how the Create Record Form, Record Banner, and Record Detail currently look. Work through the pages in your site and screenshot these components to establish the current state.
From Salesforce Setup, navigate to Digital Experiences → Settings and enable “Use Lightning Web Components on your record pages in Aura sites”.
Review your site again and ensure that components still render as expected. Be particularly aware of any custom CSS overrides that may need to be refactored due to this update.
Make any necessary adjustments so that your site largely renders as before, using the new framework for these components.
How can I prepare in production?
Once you’ve tested the changes in your sandbox environments, prepare to migrate them to production.
Outside of core business hours, enable “Use Lightning Web Components on your record pages in Aura sites”, and then make the same adjustments you applied in your sandbox environments for components to still render as required.
Enable Secure Roles Behavior and Update Sharing Group References in Sandboxes
What does this impact?
Salesforce is adjusting the name of a standard group from “Roles and Subordinates” to “Roles and Internal Subordinates” before you enable Digital Experiences.
If you already have Digital Experiences enabled in a sandbox or a sandbox that was created after February 8th, 2024, this update is expected to have no impact. If you have a preview sandbox with this update enabled that hasn’t been refreshed since Winter ‘25, no impact is expected either.
If you have any code or customization referencing the old name, be sure to update it to the new name. This change is being applied to sandboxes, with Salesforce set to enforce changes in Production orgs at a later time.
No Code and Pro Code:
- Search for references to “Roles and Subordinates”, “roleAndSubordinates”, “RoleAndSubordinates”, and “roleAndSubordinate”.
Note: References could appear in SOQL Queries, Apex, Flows, Components, API Integrations, and other metadata.
How can I prepare in a sandbox?
Find all references to the old labels and update them to “Roles and Internal Subordinates”. Enable the test run and ensure that references continue to work and run without any errors. Be sure to deploy these changes and enable the test run across your sandbox environments.
How can I prepare in production?
Salesforce is not enforcing this in Production orgs in the Summer ‘25 release; enforcement for Production orgs is planned for a later time. This is a curious decision, as if you create a sandbox during the transition window from Production, any references to the old labels will break and start to error.
However, you can choose to prepare your Production org ahead of time by deploying any changes from sandboxes to your live system and enabling the test run of this update.
Read more:
- Enable Secure Roles Behavior and Update Sharing Group References in Sandboxes (Release Update)
- Prepare for Changes to “Role and Subordinates” Group (roleAndSubordinates)
Evaluate Criteria Based on Original Record Values in Process Builder
What does this impact?
In what is likely to be one of the last updates for Process Builder, Salesforce is fixing a bug with evaluation criteria.
If you have a process with multiple criteria, a record update now checks the original value of a field that began the process with a null value.
This can impact processes where “Do you want to execute the actions only when specified changes are made to the record?” is selected, or if a process uses ISCHANGED().
As Salesforce will stop supporting Process Builder and Workflow Rules from December 31st, 2025, it’s time to migrate these to Flow if you haven’t already.
If you don’t have capacity to shift to Flow in time, then follow the below steps to prepare for the update.
No Code:
- Review Process Builder for criteria where:
- “Do you want to execute the actions only when specified changes are made to the record?” is checked.
ISCHANGED ()is used.
Pro Code:
- Scan Flow metadata where the Type is Workflow to find Process Builders that use
ISCHANGED(). - In addition, you want to find where “Do you want to execute the actions only when specified changes are made to the record?” is set. This is usually represented by an additional
myVariable_oldwithin conditions.
How can I prepare in a sandbox?
Identify impacted Process Builders and develop test cases so that, once the update is enabled, you can ensure they still fire as expected. Make sure to include a variety of different scenarios and plan tests that include blank fields.
Enable the test run and go through your test scenarios to ensure you still get the expected results.
You may need to tweak your conditions or logic if the automations no longer work as before.
How can I prepare in production?
Deploy any changes to Process Builders outside of core business hours to avoid impacting users. Activate the latest versions of the processes and enable the test run.
Run through the test scenarios and make sure they continue to produce the expected result.
Run the Lightning Knowledge Migration Tool
What does this impact?
Salesforce is migrating Classic Knowledge to the Lightning Knowledge Object Model. Starting with Summer ‘25, the Classic Object Model is no longer available.
This means you’ll need to run the Knowledge Migration Tool to migrate to the Lightning Knowledge Object Model and its functionality. You can use Lightning Knowledge in Salesforce Classic, but it has limitations.
No Code and Pro Code:
- Review Knowledge Settings and see if “Enable Lightning Knowledge” is checked.
How can I prepare in a sandbox?
Salesforce recommends testing this update in a full copy sandbox. You can test it using another sandbox type, but there is a high likelihood of “data corruption” when using a partial copy sandbox.
Run the Lightning Knowledge Migration tool in your sandbox and then validate the results. As Lightning Knowledge uses a different structure than Classic Knowledge, this could upset existing customizations.
Post-migration, ensure fields and actions are added to page layouts, and that layouts are assigned correctly to record types and profiles. Check that Approval History, Files, Related Cases, Work Orders, and Work Order Line Items related lists are added to layouts if you use these features.
In Lightning Knowledge, grant permissions to the Knowledge Object instead of per Article Type, as in Classic Knowledge. Ensure users can still edit or publish the necessary articles and consider introducing validation rules if you only want users to be able to adjust certain articles. Assign record types to profiles and permission sets to control the types of articles users can create.
As Knowledge can also be used in Experience Cloud, ensure those users retain access to the required functionality post-migration.
If you are using multiple article types in Classic Knowledge, be sure to check communication channel mapping, dependant picklists, field-level security, formula fields, validation rules, other automations (e.g. Flow, Approval Processes), and any custom elements (eg. Visualforce) post migration to ensure these still work as before.
How can I prepare in production?
Ensure that the Lightning Knowledge Migration tool is enabled. If it’s not, contact Salesforce Support to enable this feature. Migrate any metadata adjustments you had to make in your sandbox during the test run of the migration process.
Run the Lightning Knowledge Migration tool, then run tests to ensure functionality works as before and users can perform the same actions.
Salesforce Platform API Versions 21.0 Through 30.0 Retirement
What does this impact?
If you are using the BULK API, SOAP API, or REST API versions 21.0 to 30.0, then once this update is enabled, these calls will be disrupted.
This update does not impact the API versions used by Apex Classes, Apex Triggers, Visualforce Pages, Flows, and Process Builders. It does not impact the B2B Classic/Visualforce product, Custom Apex REST and SOAP Web Services, or versioned metadata components in a managed package.
However, it’s possible that code references may reference outdated endpoints (e.g. Visualforce).
No Code and Pro Code:
- Navigate to Salesforce Setup → Event Log File Browser.
- Set Event Type to “Api Total Usage” and expand the date criteria.
- Download the returned CSV files and review them.
- Search the log files for references to API versions below 31.0.
Note: Enterprise, Unlimited, and Performance Edition have access to API Total Usage log files with one-day data retention. For an additional cost, you can access all log file types with up to one year of data retention.
If you are using the free version of Event Monitoring, be sure to check files periodically.
How can I prepare in a sandbox?
For each item in the log files that uses the impacted API versions, review the Connected App ID or Connected App Name to learn where requests are coming from. If the Connected App ID uses the prefix “888”, contact Salesforce Support for app details.
The file will also provide additional clues such as the ENTITY_NAME, which shows which objects were accessed; API_RESOURCE, which shows which resource was used; and USER_ID, which shows the user that made the request.
Update API requests to use later versions, ensure they still work as expected, and refer to later log files to make sure they are using an API version greater than 30.0.
How can I prepare in production?
Review the log files to determine which applications are using older API versions.
Update each integration to use later API versions and retest to ensure the functionality still produces the expected result. If you want to take a risk-averse approach, you could choose to migrate different functionality on a rolling basis.
Read more:
- Salesforce Platform API Versions 21.0 Through 30.0 Retirement (Release Update)
- Salesforce Platform API Versions 21.0 through 30.0 Retirement
Update Your Trusted URLs for the Latest CSP Directives
What does this impact?
This update replaces the Adopt Updated Content Security Policy (CSP) Directive that was announced historically. Salesforce has since adjusted the sampling process to flag violations and introduced a new event monitoring type to flag issues. Once enforced, this could block resources from outside of your Salesforce org from being accessed to render images, iframes, and fonts.
No Code:
- From Setup, navigate to Trusted URL → Browser Policy Violations.
- Filter the list to show violation types that equal img-src (image), frame-src (iframe content), and font-src (fonts).
Pro Code:
- Schedule a daily query of the CSP Violation event type.
Note: Enterprise, Unlimited, and Performance Edition have access to CSP Violations log files with one-day data retention. For an additional cost, you can access all log file types with up to one year of data retention.
If you are using the free version of Event Monitoring, be sure to check files periodically.
How can I prepare in a sandbox?
Review the list of Trusted URL and Browser Policy Violations across all environments to get the most complete list of violations.
For each URL, add a Trusted URL, ensuring you allow the necessary CSP directives. Enable a test run of the update and test impacted functionality to ensure that images, fonts, and iframes still render as they did before enforcement.
How can I prepare in production?
Deploy any newly created or updated Trusted URLs from your sandboxes to your live environment. Clear the violation list to remove historic entries from the log. If the same URL is blocked in the future, it will be added as a new entry.
Enable the test run and test impacted functionality to make sure that external references to fonts, images, and iframes still render as expected.
Periodically check the violation list to see if new violations appear.
Verify SAML Integrations
What does this impact?
Salesforce is making a security update to SAML Integrations. This can impact the following functionalities:
- SAML SSO where users log in to Salesforce via a third-party identity provider, such as Okta.
- SAML SSO where users log in to a third-party app via Salesforce. These configurations use connected apps.
- SAML SSO between Salesforce orgs or Experience Cloud sites.
- All SAML single logout configurations.
If you are using SAML SSO, be sure to check changes before this update is enforced.
No Code and Pro Code:
- Review Login History.
- Review My Domain Settings and Experience Cloud Sites to see if any SSO providers are listed on the login page.
- Review Single Sign Settings to see if SAML is enabled.
- Review Connected Apps and External Client Apps that are SAML-enabled.
How can I prepare in a sandbox?
The advice from Salesforce is to set up your SAML SSO configurations in a sandbox as soon as the Summer ‘25 release becomes available. You can be among the first to get your hands on Summer ‘25 by spinning up a preview sandbox within the release window.
Using a Summer ‘25 sandbox, liaise with the necessary internal and external teams to set up your SAML SSO configurations. This update itself doesn’t have a test run, so in this case, the test is whether SAML SSO works (or not!).
How can I prepare in production?
Following the Summer ‘25 release, ensure that SAML SSO still works as expected.
If you experience issues, consider temporarily turning this off to allow users to access the system with a username and password while you work to resolve the issues.
Enable ICU Locale Formats
Just a reminder that Salesforce has enforced this for orgs in the Spring ‘25 release. If Salesforce attempted this and it failed, the org admin would’ve received an email, and they will try again in the next release (Summer ‘25).
Summary
With this release, a number of changes are coming that could cause issues if you don’t prepare in time!
Be sure to start your planning for these updates early to ensure you are ready for when Salesforce is due to auto-enforce these changes from May 2025 onwards.
Comments: