Password Reset Login Subtype Label Is Changed
For more consistency with naming conventions, we renamed the label for the password reset login subtype in the Login History. When a user resets their password, the Login Subtype column now displays UI Password Reset instead of Change Password.
Where: This change applies to Lightning Experience (not available in all orgs) and Salesforce Classic in all editions.
Identify the Origin IP Address for Logins with One or More Proxies
To monitor login activity more thoroughly and prevent potential threats, you can now see what value the client passed in the X-Forwarded-For header of their HTTP request to Salesforce. For logins that redirect users to one or more proxies, the X-Forwarded-For field is sometimes used to store the origin IP address of the client. Use the new Forwarded for IP column in the Login History and related fields to track the origin IP address. This change isn’t available for OAuth and single sign-on (SSO) logins.
Where: This change is available in Lightning Experience (not available in all orgs) and Salesforce Classic in all editions.
Why: Salesforce tracks the Source IP of login requests, but for logins that redirect through multiple proxies, the origin IP address isn’t always reflected in the source IP. In this case, the Forwarded for IP value is a better way to tell where the original request came from.
How: From Setup, in the Quick Find box, enter Login History, and then select Login History. Add the Forwarded for IP column to your Login History list view.
Forced Login is Permanently Disabled in Winter ’25
To improve security, in Winter ’25, users can no longer log in to Salesforce by passing a username and password as URL query string parameters in the login URL, also known as forced login. This change will break implementations and third-party integrations that use a forced login via a URL, as well as direct login (autologin) links. To avoid service disruptions, update integrations that use forced login.
Where: This change applies to Lightning Experience (not available in all orgs) and Salesforce Classic in all editions.
When: This change takes effect in Winter ’25.
Why: In the Spring ’22 release, Salesforce enforced a release update that disabled the ability for users to log in using their credentials, but some orgs are still using this feature. With this change, forced login is permanently disabled in all orgs.
How: To prepare for the change, first review org usage of forced login. From Setup, in the Quick Find box, enter Login History, and then select Login History. View and download your org’s login history for the past 6 months. Review the HTTP method column. If the HTTP method is GET, and there’s no entry for Login Subtype, it indicates that users are using forced login.
Stay on Top of MFA Compliance
Multi-factor authentication (MFA) is turned on by default for direct logins to production orgs as of April 8, 2024. Starting in Summer ’24, admins get in-app reminders if they don’t comply with the MFA requirement.
Where: The change to turn on MFA by default applies to Lightning Experience, Salesforce Classic, and all versions of the mobile app in all editions. The change to add in-app reminders applies to Lightning Experience and all versions of the mobile app in all editions.
How: For more information on these changes, see MFA Is On by Default for Direct Logins to Production Orgs and Salesforce Admins Get In-App Reminders If MFA Is Turned Off
Verify Email Addresses to Meet the Email Verification Requirement
To complete enforcement of the email verification requirement introduced in the Spring ’22 major release, Salesforce now requires all users in all orgs and Experience Cloud sites to verify their email address. If a user sends an email from an unverified email address, Salesforce rejects this email message and doesn’t complete the send. Unverified email addresses can’t be used for sends until the user verifies their email address or resets their password. To avoid disruptions, ensure that all user email addresses are verified.
Where: This change is available in Lightning Experience and Salesforce Classic (not available in all orgs) in all editions.
Who: This requirement applies to all users in all orgs and Experience Cloud sites, including employee, customer, and partner users across sandbox and production instances. Most users affected by this change are SSO users because non-SSO users verify their email address when they sign up. However, some non-SSO users can be affected if they use email addresses that were added to Salesforce before the current verification process existed.
Email verification for org-wide email addresses was already and continues to be required. Any features that use org-wide email address functionality, such as Service Email, already meet email verification requirements.
Why: In past releases, Salesforce enforced this requirement for all orgs and Experience Cloud sites except for paid production instances with single sign-on (SSO) users. In Spring '24, Salesforce started enforcing the requirement for paid production instances with SSO users, but only for instances created after Spring '24. With the Summer ’24 release, Salesforce now enforces the requirement for all orgs and Experience Cloud sites, including all paid production instances with SSO users, regardless of when they were created.
How: As a Salesforce admin, check a user’s email verification status by viewing the user’s details. From the Users page in Setup, select a user and check the Email field. When the user completes verification, the Verify link changes to Verified. Users can also see their own email verification status from the Advanced User Details page.
For unverified users, you have several options for verifying their email address. The best method for your use case depends on how many users you’re verifying and what kind of experience you want to provide.
For an individual user, you can initiate verification or the user can do it themselves. With either of these methods, the user receives a Salesforce-branded verification email that can’t be customized.
For a large number of users or to have more control over branding and the user experience, use these options.
- To verify multiple users at once, use the async email method. You can customize the verification email template to suit your brand.
- To automatically verify all email addresses that belong to a specific domain, verify the domain using DomainKeys Identified Mail (DKIM). Use this method when you don’t want users to receive a verification email at all.
Salesforce also verifies a user’s email address during some processes, such as password reset and device activation.
For a full overview of the different ways to verify email addresses, see User Email Verification in Salesforce Help.
Use REST API for Access to External Client App OAuth Consumer Credentials (Release Update)
To follow recommended security standards, use the new credentials Connect REST API resource instead of Metadata API to access External Client App OAuth consumer credentials.
Where: This change applies Group, Essentials, Professional, Enterprise, Performance, Unlimited, and Developer editions.
When: Salesforce enforces this update in Winter ‘25. To get the major release upgrade date for your instance, go to Trust Status, search for your instance, and click the maintenance tab.
Who: This change applies to existing External Client App users who use Metadata API to access consumer credentials.
Why: Accessing consumer secrets through the credentials endpoint of the Connect REST API removes the possibility of accidentally committing consumer secrets to source control.
How: Access consumer secrets through the credentials endpoint of the Connect REST API. Unless you contact Salesforce Customer Support to continue using Metadata API, your external client apps can’t access consumer secrets via Metadata API after Winter ’25.
Enter New Firebase Information Required for Android Push Notifications
The legacy Firebase Cloud Messaging API server key is no longer accepted for configuring Android push notifications on mobile connected apps. Because of a change in how Google handles push notifications, Android mobile connected apps now require the Admin SDK private key and project ID from a Google Firebase project.
Where: This change applies to mobile connected apps with Android push notifications. Connected apps can be created in Group, Professional, Enterprise, Essentials, Performance, Unlimited, and Developer editions.
How: Get the required information from your Firebase project in the Google Firebase Console. Then submit the information to your mobile connected app’s settings in App Manager.
Migrate to a Multiple-Configuration SAML Framework (Release Update)
If you see this release update, your Salesforce instance is using our original single-configuration SAML framework, which supports single sign-on (SSO) with only one external identity provider. With this release update, we’re removing support for the single-configuration SAML framework and supporting only the multiple-configuration SAML framework. To preserve your existing configuration, follow the steps to apply this update. If you don’t, your SSO configuration stops working when this update is enforced. This update was first made available in Spring ’24. It was scheduled to be enforced for all instances in Summer ’24, but we postponed the enforcement date for production instances to Spring ’25. This update is still enforced for sandboxes in Summer ’24.
Where: This change applies to Lightning Experience and Salesforce Classic in Enterprise, Unlimited, and Developer editions.
When: This update is enforced for production instances in Spring ’25 and is enforced for sandboxes in Summer ’24. This update was scheduled to be enforced for all instances in Summer ’24 but was postponed to Spring ’25 for production instances only. To get the major release upgrade date for your instance, go to Trust Status, search for your instance, and click the maintenance tab.
Why: We’re no longer supporting the single-configuration SAML SSO framework that you’re currently using. When this update is enforced, you’re required to use a multiple-configuration SAML framework. To keep using your existing SAML SSO configuration, migrate to the multiple-configuration framework. Otherwise, your SAML SSO stops working for you when this update is enforced.
How: These changes apply to your existing SAML SSO configuration.
- SAML responses from your identity provider must include the
audienceattribute. - Your Salesforce Login URL changes.
- If Salesforce can’t parse a SAML response, it isn’t recorded in the login history.
Make sure you understand these changes, update your configuration accordingly, and test all changes in a sandbox before enabling this update. If you don’t, your configuration stops working when this update is enforced.
To review this update, from Setup, in the Quick Find box, enter Release Updates, and then select Release Updates. For Migrate to a Multiple-Configuration SAML Framework, follow the testing and activation steps.
Create Token Exchange Handlers More Easily
For better usability when configuring the OAuth 2.0 token exchange flow, define and enable OAuth 2.0 token exchange handlers in Setup instead of using Metadata API. Create a handler definition, link it to an Apex class, and set some of its properties, such as what types of tokens it supports and whether it can create users.
Where: This change applies to Lightning Experience (not available in all orgs) in Enterprise, Performance, Unlimited, and Developer editions.
Why: The token exchange flow simplifies your integration patterns for use cases that include a central identity provider, such as Okta, along with multiple service providers and microservices.
How: From the Token Exchange Handlers page in Setup, define and enable the handler. The ability to edit the handler in Setup isn’t currently supported. To edit its definition, use Metadata API.
Integrate Custom App Experiences with the Salesforce UI
Give users uninterrupted access across custom apps and Salesforce. With the new Single-Access UI Bridge API, use an existing Salesforce access token to load a new session in a Salesforce UI, such as a Visualforce site or mobile app. For example, when users are logged in to a headless app, redirect them to your Experience Cloud site to view Support cases without making them log in again.
Where: This change applies to Lightning Experience and Salesforce Classic in all editions.
How: Using a POST request, send an access token to the new /services/oauth2/singleaccess endpoint on your My Domain or Experience Cloud site. Salesforce returns a JSON response with a frontdoor.jsp URL. Use the URL to redirect the user and load a new, authenticated session in a custom interface.