PRO TIPS

Winter '25 and Spring '25 Release Updates

Winter '25 Release Updates

We've previously shared release updates for the Winter '25 release, which will be live in all orgs on or before October 12, but there have been some late-breaking cancellations and delays:

These items have been cancelled, and will not be enforced:

  1. Adopt Updated Content Security Policy (CSP) Directives: to improve security in Lightning pages, Salesforce will update its practices on embedding external content. This may cause some desirable content (like embedded fonts) to be blocked in sites. Salesforce has told users that this update will re-appear in a future release (TBD), but for now, they are working to improve reporting around affected content.
  2. Enforce Sharing Rules when Apex Launches a Flow: previously, this was to be enforced for all instances in which an Apex class launched a Flow; now it will only apply to Flows saved in API version 62 and above.

These two items have been delayed, so you should still plan on addressing them before the new enforcement date:

  1. Transition to the Lightning Editor for Email Composers in Email-to-Case: the new email-to-case email editor finally goes GA with a large upgrade in functionality, adding features like drag and drop attachments, inline images, and full-screen editor mode. You can enable this now if you want to get a head start.
  2. Disable Ref ID and Transition to New Email Threading Behavior: Salesforce has been on a multi-year journey to change threading behavior for emails tied to records. You may still see a banner directing you to transition to Lightning Threading, and Salesforce does recommend making the transition despite the enforcement delay.

This item was previously announced as enforced, but has been removed from the release notes without formally being cancelled or postponed:

  1. Migrate from Maintenance Plan Frequency Fields to Maintenance Work Rules: for users of Field Service, this is a potentially big change. Maintenance Plans have been able to generate recurring schedules in two different ways; either by using Frequency fields found on the Maintenance Plan record itself, or by using newer, Maintenance Work Rules that offer more flexibility in defining recurring schedules. Salesforce has been deprecating these old fields for years and originally announced they would finish the process in Winter '25.

These remaining items will be enforced in the release:

  1. Create and Verify a Default No-Reply Organization-Wide Email Address to Send Email: Address this if you do nothing else! Salesforce has steadily tightened email security policies, and this update continues the trend. Going forward, every org will be required to have a default no-reply Organization-Wide Email Address (settable in settings) in order to ensure email is delivered. For most organizations, this is an address like info@xyz.org or no-reply@xyz.org. It's always been good practice to have one of these, but now it's going to be a formal requirement.
  2. Change Einstein Activity Capture Permissions for Sales Engagement Basic Users
  3. Enable EmailSimple Invocable Action to Respect Organization-Wide Profile Settings
  4. Pass the Conversation Intelligence Rule Name as Input to a Flow: this is a new feature; if you use Service Cloud Voice, its conversation intelligence rules can launch Flows. Now, you can pass the name of the rule that launched the Flow as an input to the Flow, which can be useful for troubleshooting or processing inside of it.
  5. Prevent Guest User from Editing or Deleting Approval Requests: this update has been delayed from a prior release; basically, it prevents unauthenticated guest users (like those in partner sites) from editing approval requests, although they can continue accepting or rejecting them.
  6. Review and Update Settings to Capture Leads from LinkedIn
  7. Run Flows in Bot User Context
  8. Turn On Lightning Article Editor and Article Personalization for Knowledge: in the same vein, a large upgrade to the Lightning Knowledge editor goes live, enabling better localization (both in language and in formatting dates), the ability to create collapsible sections in long articles, and to leverage existing quick text and audience segmentation features. Just like the email editor, you can enable this now if you want to get a head start.
  9. Enforce View Roles and Role Hierarchy Permission When Editing Public List View Visibility: users have long had the ability to create and edit list views on Salesforce objects (like the Accounts or Contacts tabs) if you granted the appropriate permission. As part of that process, they can also specify who can see the list view. Historically, those users have been able to see the org's full role hierarchy as a matter of course. Salesforce is now separating those permissions; meaning that if a user needs to grant access to a list view and see the role hierarchy, they'll need to have both permissions applied to either their Profile or via a Permission Set.
  10. Use REST API for Access to External Client App OAuth Consumer Credentials: Salesforce has always allowed developers to use the Metadata API to access OAuth credentials to use in their applications, but this has led to cases where those credentials get stored in source control management (e.g. Github) and exposed publicly. To combat this, Salesforce has added a credentials resource to the Connect REST API that can retrieve OAuth credentials. You should note, however, that if your application relies on Metadata API, Salesforce will remove the capability after this release unless you file a case with support before Winter '25 is released for your org.

Spring '25 Release Updates

These items will be enforced in the Spring '25 release, which will be pushed to orgs in January or February 2025:

  1. Enable ICU Locale Formats: This has been enforced on a rolling basis since Spring '24. Salesforce is converting its backend handling of Locale settings for things like dates, times, and currencies from the Java Development Kit (JDK) format to the ICU format set by the Unicode Consortium to comply with industry standards. This may lead to minor adjustments to data presented to users. It could also affect custom Apex code, or unmanaged packages that haven't yet been updated–but all managed Apex packages should have been updated to comply.
  2. Enable LWC Stacked Modals: to improve page load performance in the browser, Salesforce is converting more of the user interface from legacy Aura components to Lightning Web components. That change means minor changes in the appearance of the UI for all users, and has special implications for developers building custom quick actions in either Aura or LWC.
  3. Enable Secure Redirection for Flows: if you launch a screen flow from an action link/button in Salesforce, you can use the retUrl parameter to control where the user is redirected after the Flow finishes. To improve security, Salesforce is going to apply stricter validation to those URLs, which could cause some existing redirections (especially external ones) to fail. You can solve this issue by adding the URL to Trusted Sites in Setup.
  4. Enforce Permission Requirements Defined on Built-In Apex Classes Used as Inputs: admittedly, this one feels like it's using the word to define the word in the Salesforce documentation. We believe what it's driving at is that, when using an Apex action in a Flow, the user will need to have access to the underlying records being affected (e.g. Contacts) if the Apex action is defined to enforce user permissions.
  5. Enforce Rollbacks for Apex Action Exceptions in REST API: this has been postponed a couple of times over, but should now be enforced in Spring '25. You may recall it from its original title: Enforce Rollbacks for Custom Invocable Action Exceptions in Connect REST API. Before this update was enforced, Apex actions run via the REST API were not rolled back if they encountered exceptions, meaning database changes could be applied inconsistently (e.g. some actions would succeed, and some would fail, meaning half the records you expected to be created might actually be, and half wouldn't). Now, Salesforce will roll back those failed transactions.
  6. Enforce View Roles and Role Hierarchy Permission When Editing Public List View Visibility: users have long had the ability to create and edit list views on Salesforce objects (like the Accounts or Contacts tabs) if you granted the appropriate permission. As part of that process, they can also specify who can see the list view. Historically, those users have been able to see the org's full role hierarchy as a matter of course. Salesforce is now separating those permissions; meaning that if a user needs to grant access to a list view and see the role hierarchy, they'll need to have both permissions applied to either their Profile or via a Permission Set.
  7. Sort Apex Batch Action Results by Request Order: if you run an action that submits a large number of records to the queue (say, 1,000), Salesforce breaks those records into batches (for example, 200). If you query the result of the operation, Salesforce will show you the five batches and whether they were successfully processed. Until this release, if any batch encountered errors, Salesforce would return it at the front of the results to your query. With this release, that behavior is changing; now any batch that encounters errors will show up in the order in which it was originally received by Salesforce for processing.
  8. Use an Apex-Defined Variable for All Intelligence Signal Types: this is a newly-added feature for Service Cloud Voice customers, which allows admins and developers to capture intelligence signal data (e.g. a caller is frustrated) and process it inside Flows; this, for example, lets you feed data to Next Best Action recommendations.
  9. Verify Your Return Email Address for Sender Verification: to comply with increasing email security standards, Salesforce will stop sending emails on behalf of users that have not verified their addresses. This shouldn't affect many users (because most verify their addresses as part of account setup), but you can run a report of any users who haven't done so by reporting on the User Verified Email field, and sent those users the verification email from their User profile. Note that there is no release update in Setup for this item.
  10. Migrate to a Multiple-Configuration SAML Framework: this only applies to a subset of orgs that use single sign on with an external identity provider like Okta or Azure–if you don't see the release update in your org, there's nothing you need to do. This update represents an upgrade for Salesforce's framework; if the release update appears in your org, follow the steps to ensure SSO continues to function properly.
  11. Verify SAML Integrations: Salesforce continually upgrades its SAML frameworks to increase security, which is good for everybody. But, some upgrades coming in Spring '25 may cause issues with client SAML configurations. Salesforce highly recommends testing SAML configurations in Spring '25 preview sandboxes, which should become available in November or December.

As always, Prolocity is here to help you navigate your system administration needs–please reach out if you need further guidance! Essentials subscribers can also join us for a free Office Hours session to ask questions about how these changes might affect your org.