Releases / Admins / Developers

Salesforce Spring ‘25 Release: What to Expect and How to Prepare

By Tom Bassett

It’s Salesforce release season yet again, and Spring ‘25 will soon be upon us!

Salesforce enforces release updates in each release that change the behavior of certain features or products. It’s advisable to prepare ahead of time by testing updates in a sandbox before they are enabled in your live system from January 2025 onwards.

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!

READ MORE: Ultimate Guide to Salesforce Release Updates

Spring ‘25

When the Spring ‘25 release is rolled out to Salesforce orgs, a number of release updates will be auto-enabled. Be sure to review the below list so you can prepare your org accordingly and review due dates against the updates in your org to allow ample time.

While we try to provide general steps you can take to enable and test these updates, the exact steps will depend on the configuration within your Salesforce org.

Note: If you are using any managed packages, reach out to the provider to make sure any packaged metadata for the impacted features is ready for these changes.

When planning changes in a production environment, make changes 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/clients.

Change Einstein Activity Capture Permissions for Sales Engagement Basic Users

What does this impact?

If users are currently using Einstein Activity Capture via the Sales Engagement Basic User permission set, they will lose access unless they are assigned Standard Einstein Activity Capture permission set. It’s also worth noting that any cloned permission sets will lose this functionality too.

You’ll need to determine if users have the correct level of access to use Einstein Activity Capture going forward.

No Code:

  • Create a Permission Set List View that shows permission sets with Use Einstein Activity Capture

Pro Code:

  • Search in Permission Set Metadata for reference to AutomaticActivityCapture

Review the Sales Engagement Basic User permission set along with any custom permission sets to see if these are assigned to users, permission set groups, or user access policies.

Note: Ignore permission sets only assigned to system users, such as Platform Integration User.

How can I prepare in a sandbox?

It’s very unlikely that Einstein Activity Capture itself will be enabled in a sandbox, as having this on in more than one environment can cause issues.

However, be sure to follow the No Code or Pro Code steps to access the users that will be impacted by this change and adjust their permissions initially in a sandbox so they have the Standard Einstein Activity Capture permission set.

Users may still need the Sales Engagement Basic User permission set for the other permissions it provides, so be sure to remove this from users only if they no longer need any of those permissions.

How can I prepare in production?

Once you’ve made the changes in your sandboxes then adjust permissions in production. Once changes have been made, be sure to check that Einstein Activity Capture is still working for users with access.

Once the Spring ‘25 update has been rolled out to production and the Sales Engagement Basic User permission set no longer has access to Einstein Activity Capture, make sure users are still able to use Einstein Activity Capture without issues.

You can view the connection status for Einstein Activity Capture users from Salesforce Setup.

READ MORE: Change Einstein Activity Capture Permissions for Sales Engagement Basic Users (Release Update)

Enable ICU Locale Formats

What does this impact?

Salesforce is migrating from Oracle’s Java Development Kit (JDK) for Locale Formats to ICU Locale Formats.

In Salesforce, your locale defines the format for date and time, user’s names, addresses, and commas/periods in numbers. It sets the start day of the week, and if you are using one currency, it also sets the default currency.

No Code and Pro Code:

This update may have a slightly later enforcement date than other updates due this release. Salesforce is enforcing this update on a rolling basis until Summer ‘25. From Salesforce Setup, you can differ the update until Summer ‘25 if you are using the JDK Formats.

How can I prepare in a sandbox?

If you are using ICU Locale Formats and “Enable ICU formats for en_CA locale” are enabled, no further action is required. If you haven’t yet enabled ICU formats for en_CA locale, then do this in a sandbox initially to test if it impacts your existing processes. This is only likely to have an impact if users are using this locale.

If you are using the Java Development Kit (JDK) Locales, Salesforce provides a guide on how to prepare and adopt the new format ahead of time. Steps include enabling a test run and updating Apex classes, Apex triggers, and Visualforce pages.

Follow the step-by-step instructions provided by Salesforce in your sandbox environments initially and test updated or impacted functionality to ensure everything works as expected.

How can I prepare in production?

Once the update has been enabled in your sandboxes and you are happy everything works as before, you can deploy changes to the Production org.

Ideally, updates should be performed outside of working hours so as not to impact users. If possible, do this ahead of enforcement, so if there is an issue you can disable the update and roll back changes with time to rework the solution before enforcement.

READ MORE: Enable ICU Locale Formats (Release Update)

Enable LWC Stacked Modals

What does this impact?

Salesforce continues to migrate internal components from Aura to Lighting Web Components (LWC). In this update, changes will impact modals (pop-ups) that appear when you create a record, for example.

Salesforce describes these UI changes as minor; however, if you use Custom Actions to display an Aura and LWC component you may need to tweak these so the user experience is the same.

No Code:

  • Review custom actions that launch an LWC or Aura component.
  • Review standard actions that are overridden with a custom component.

Pro Code:

  • The below query will return custom actions defined in buttons, links, and actions that are of type Aura component or Lightning Web Component:

SELECT id, DeveloperName, EntityDefinition.DeveloperName, Label, ManageableState, MasterLabel, Type FROM QuickActionDefinition where type = 'LightningComponent' or type ='LightningWebComponent'

  • Search Object Metadata for the below references to find any standard actions (new, edit, etc.) that are overridden with custom components <type>LightningComponent</type>

How can I prepare in a sandbox?

Compile a list of components that are being used as action overrides in the system using the above steps. Review the release update post-save navigation behavior table to understand the changes expected once the release update is enabled.

Test components and note the current post-save navigation behavior. Enable the test run and re-test each component. If the post-save behavior has changed, work with a developer to adjust as desired.

How can I prepare in production?

If you decide for users to see a new post-save behavior, ensure you communicate this to users in advance.

As always, try to make any changes to a live system outside of working hours to not negatively impact users.

Deploy any related changes from sandboxes to your production environment. Enable the test run and test each component to ensure that the post-save behavior is as expected.

READ MORE: Enable LWC Stacked Modals (Release Update)

Enable Secure Redirection for Flows

What does this impact?

If users run a Flow with a retURL parameter (which tells the Flow where to navigate when done), this redirect may fail going forward. If the URL provided is not on the Trusted URLs for Redirects in Setup, then it will need to be added to the list to continue to work as expected.

No Code:

  • It’s most likely a retURL is specified in a custom action. Refer to your Custom Actions to see if they set this behavior.
  • If you do find an action setting this behavior, be sure to test and add the target URL to Trusted URLs for Redirects.

Pro Code:

  • Search your Metadata for retURL
  • It’s most likely that this could appear in Custom Actions, but this could also be set in Fields, Visualforce, Lightning Web Components, etc.
  • If the parameter is related to a Flow, the target URL will need to be added to Trusted URLs for Redirects under Setup.

Note: This may appear in Salesforce under “Enable Secure Redirection for Screen Flows” as Salesforce appears to have changed the wording of this update.

How can I prepare in a sandbox?

Follow the No Code or Pro Code steps to access the areas of the system potentially impacted by this update. Once you’ve determined the functionality impacted, consider if this functionality is being used in Salesforce or Experience Cloud so you can test all use cases and personas.

Enable the test run in a sandbox and run through each of your use cases. For each use case that fails, you’ll need to add a Trusted URL for Redirects under Setup.

Although the technical details of this update seem to apply more to Salesforce Classic than Salesforce Lightning, be sure to test in both if users are using both.

Once all use cases are tested and work as expected, you can deploy the updated Trusted URLs for Redirects to your other sandboxes and repeat the testing steps.

How can I prepare in production?

Once you’ve deployed the Trusted URLs for Redirects, enable a test run and test impacted functionality to make sure it still works as expected.

Aim to make changes outside of working hours to allow time for testing and rollback should there be issues before users’ next login.

READ MORE: Enable Secure Redirection for Flows (Release Update)

Enforce Permission Requirements Defined on Built-In Apex Classes Used as Inputs

What does this impact?

Going forward, if you have a Flow or Process Builder that runs an Invocable Apex Method, the context for which this runs could change. Apex called in this way will run in the current context if it calls a built-in Apex class used as an input.

No Code:

  • Search Apex for @InvocableMethod
  • Review Flow, Process Builders, Apex, or Einstein* Features for references.

Pro Code:

  • Search Apex Metadata for @InvocableMethod
  • Once you’ve found any matching references, search Flow, Process Builders, Apex, or Einstein* Metadata for those references.

* An Einstein bot, prompt, or agent can call an InvocbaleApex Action.

How can I prepare in a sandbox?

Enable the test run for this release update.

Once you’ve identified your Invocable Methods, it’s probably most efficient to test that all still work as expected. There are numerous system methods that Salesforce provides, and trying to isolate these test cases individually could be time-consuming.

Remember, an Invocable Apex Action can also be called from the REST API. Be sure to test actions that way if users or integrations call these via the REST API.

Once you’ve tested the updates and associated Apex Actions, assuming everything works as expected, you can deploy changes to your other environments and repeat your testing.

How can I prepare in production?

Once you’ve enabled the test run in a sandbox and test associated functionality, it’s time to plan making the changes live in your production instance.

Plan these changes in a way that doesn’t impact users (eg. outside of working hours). That way, you can deploy changes and test that things work as expected without disrupting users.

READ MORE: Enforce Permission Requirements Defined on Built-In Apex Classes Used as Inputs (Release Update)

Enforce Rollbacks for Apex Action Exceptions in REST API

What does this impact?

If you use the REST API to call an Apex Action, historically, this wouldn’t be rolled back if there was an exception. Going forward, this will be rolled back once this update is enforced.

No Code:

  • Search Apex for @InvocableMethod

Pro Code:

  • Search Apex Metadata for @InvocableMethod

How can I prepare in a sandbox?

It’s most likely that a REST API call will be initiated by an external system, but it’s possible to call these manually using a tool such as Workbench or Postman.

Enable the test run of the release update. Use the No Code or Pro Code steps to determine if there is Apex that can be triggered via the REST API and then run Apex to ensure it still runs successfully and produces the expected result.

How can I prepare in production?

Plan for changes to your live system to happen outside of working hours.

Deploy any changes from your sandboxes you had to make post enablement of the test run in the previous step.

Enable the test run and test impacted functionality to ensure it still works as expected.

READ MORE: Enforce Rollbacks for Apex Action Exceptions in REST API (Release Update)

Enforce View Roles and Role Hierarchy Permission When Editing Public List View Visibility

This update was covered in the Salesforce Winter ‘25 Release: What to Expect and How to Prepare but has now been adjusted, so it will be enforced in Spring ‘25 instead.

READ MORE: Enforce View Roles and Role Hierarchy Permission When Editing Public List View Visibility (Release Update)

Migrate to a Multiple-Configuration SAML Framework

This is an update you may have seen before in Salesforce Summer ‘24 Release: What to Expect and How to Prepare. This will now be enforced in Spring ‘25, rather than Summer ‘24, as originally proposed.

This is available only if you’re using a single-configuration SAML framework. If you don’t see this release update, no action is currently required.

READ MORE: Migrate to a Multiple-Configuration SAML Framework (Release Update)

Sort Apex Batch Action Results by Request Order

What does this impact?

Currently, when an Apex Batch Job runs, errors are shown at the top of the results with successes at the bottom of the results. Going forward, results will be shown in the order the requests were received.

No Code and Pro Code:

  • View Apex Jobs from Setup and look for jobs with type BatchApex

How can I prepare in a sandbox?

Find Apex Batch Jobs using the No Code and Pro Code steps above and enable a test run of the release update.

Wait for the Apex Batch Job to next run and ensure this runs as expected, especially if you have a custom logging mechanism built in that could rely on errors being at the top of the list.

How can I prepare in production?

Aim for any changes to a Production org to happen outside of the working day to avoid any impact on users.

Deploy any changes from the sandboxes you made in the previous step. Enable the test run and ensure that Apex Batch jobs continue to work as expected.

READ MORE: Sort Apex Batch Action Results by Request Order (Release Update)

Use an Apex-Defined Variable for All Intelligence Signal Types

What does this impact?

This update relates to Service Cloud Voice with Amazon Connect, Service Cloud Voice with Partner Telephony from Amazon Connect, or Service Cloud Voice with Partner Telephony.

After enforcement, if you don’t set intelligenceSignals as an input for Autolaunched Flows and Recommendation Strategy Flows, these will error.

No Code and Pro Code:

  • From Salesforce Setup, review Conversation Intelligence rules that run an Einstein Next Best Action or Autolaunched Flow.
  • Review any custom Aura components that use an INTELLIGENCE_SIGNAL for references to Einstein Next Best Action or Autolaunched Flows.

How can I prepare in a sandbox?

Ensure that Service Cloud Voice is set up in a sandbox with your Conversation Intelligence rules. Once Service Cloud Voice is set up, adjust impacted flows so they can receive the Apex-defined variable as an input variable.

Enable the test run of the update and thoroughly test different use cases that can trigger Conversation Intelligence rules that run either an Einstein Next Best Action or Autolaunched Flow.

How can I prepare in production?

Plan to release changes to your live system outside of core working hours.

Deploy updated flows from your sandboxes. Enable the test run of the release update and test all use cases to ensure the Intelligence rules still trigger as expected when they are related to either an Autolaunched or Next Best Action Flow.

READ MORE: Use an Apex-Defined Variable for All Intelligence Signal Types (Release Update)

Verify Your Return Email Address for Sender Verification

What does this impact?

Going forward, Salesforce will require any return address to be verified before they can be used.

Users receive a verification email once per release until Spring ’25. The email includes the verification link.

No Code and Pro Code:

  • Ask users to visit My Email Settings.
  • If you add /lightning/settings/personal/EmailSettings/home onto your My Domain, it’ll direct users to the correct place.
  • For example, if your My Domain was “crmtom92.my.salesforce.com”, the URL would be “crmtom92.my.salesforce.com/lightning/settings/personal/EmailSettings/home”.
  • If they see the Resend Verification Email, click this link and click the verification URL in the email from Salesforce.
  • If the Resend option is unavailable, the return address is already verified.

How can I prepare in a sandbox?

For users with access to a sandbox, if they are sending emails, then get them to visit their personal settings to make sure their sender address is verified. If it isn’t, ask them to press the verification request link and follow the instructions in the email.

How can I prepare in production?

Get users to visit their personal settings to check if their sender email address is verified. If not, ask them to click the verification link and follow the instructions in the resulting email from Salesforce.

READ MORE: Verify Your Return Email Address for Sender Verification (Release Update)

Verify SAML Integrations

This update was originally due to be enforced in the Spring ‘25 Release. Salesforce has since updated the release notes to say it will now not be enforced until Summer ‘25.

More on the Summer ‘25 update coming soon…

READ MORE: Verify SAML Integrations (Release Update)

Review and Update Settings to Capture Leads from LinkedIn

What does this impact?

If you have LinkedIn Lead Gen Forms connected to Salesforce, you need to take action for these to remain connected.

This change is due to a change in LinkedIn APIs, and as such, you need to update settings by December 16, 2024 – this date is earlier than all the other Spring ‘25 updates.

No Code and Pro Code:

  • Navigate to Lead Gen Fields and LinkedIn Accounts under LinkedIn Lead Gen from Salesforce Setup.
  • If you don’t see any connected accounts or forms, it’s unlikely you are using this feature.

How can I prepare?

The Salesforce and LinkedIn connection only supports one Salesforce instance at a time. If you wanted to test this in a sandbox, you’d have to disconnect the live integration first, which could cause leads to go into the wrong environment or be missed.

Depending on your related Business Processes, if you set this up in a sandbox, then emails could also fire from that environment to leads or users, which may not be desired if they come from the test environment.

Review your related business processes and determine where best to perform and test this update. Before you make any changes, take screenshots of the setup to have a backup of your current configuration and make sure you have a way to check leads that may be ‘missed’ during the migration or testing period.

If you decide to test in a sandbox first, then disable deliverability prior to testing if you have processes that fire emails based on lead creation.

Salesforce provides detailed step-by-step instructions on how to prepare for this release update from the page in Salesforce Setup. Follow those steps to prepare for this update:

  1. Review your LinkedIn Lead Gen Settings.
  2. Disconnect your LinkedIn account.
  3. Turn on “Use LinkedIn Lead Sync APIs with Lead Forms”.
  4. Connect your LinkedIn account.
  5. Verify your LinkedIn Lead Gen Settings.
  6. Check for unsynced leads on LinkedIn.com.
  7. Review alert.
READ MORE: Review and Update Settings to Capture Leads from LinkedIn (Release Update)

Take Action to Maintain Access to the Salesforce Outlook Integration

What does this impact?

Microsoft is updating its authentication methods, which may impact the Salesforce Outlook Integration.

Work with your Microsoft 365 administrator to ensure the necessary scopes are granted to the integration. In addition to this, Salesforce recommends using the Admin Consent Flow, which will automate this process. This link can be found on the Outlook Integration and Sync page in Salesforce Setup.

Read more:

Summary

This is a bumper update with lots of release updates being enforced on or around the Spring ‘25 release.

Be sure to plan ahead to prepare for and test release updates ahead of time to avoid impact on your Salesforce users!

The Author

Tom Bassett

Tom is a 31x Trailhead certified, 2x Slack certified, and an 11x accredited professional with over six years of experience in the Salesforce ecosystem.

Leave a Reply