The Why – Updated Browser Rules for Third-Party Cookies
As a result of regulatory and consumer pressure, major web browsers are blocking third-party cookies. Apple® Safari® and Mozilla® Firefox® already block them, and Google™ has announced that it plans to phase out these kinds of cookies in Chrome™ in 2023.
Today, users can disable a setting to allow these cookies, but browser developers indicate that they intend to permanently block third-party cookies in the future.
Impact on Salesforce Users without Enhanced Domains
Without enhanced domains, when the user’s browser blocks third-party cookies, some content in Salesforce can be blocked. For example, a landing page ending in lightning.force.com can’t load content stored in your org and accessed via a URL ending in documentforce.com.
The resulting error often mentions “cross-domain cookies” or “cross-site cookies.”
The What – Solution: Enhanced Domains
Enhanced domains make structural changes to the Salesforce domains that serve content. With enhanced domains, all Salesforce content shares a common domain, so the cookies can be shared and the browsers allow access, even when third-party cookies are blocked.
Because enhanced domains allow your users to continue using Salesforce when the browser blocks third-party cookies, they’re the future standard and required for all orgs.
My Domain was enforced in all Salesforce orgs in Winter ’22, starting in August 2021 for sandboxes and October 2021 for production orgs
Enhanced domains are the next version of My Domain. With this feature, all URLs across your org contain your company-specific My Domain name, including URLs for your Experience Cloud sites, Salesforce Sites, Visualforce pages, and content files. This feature changes domain suffixes (the part after the My Domain name) to meet the latest security standards. Also, all sandbox URLs contain the word sandbox, making them easier to identify
Enhanced domains are currently available in all orgs. All qualifying orgs created in Summer ’22 or later get enhanced domains by default. Enhanced domains are required for sandboxes and non-production orgs in Winter ’23, starting in August 2022, if you don’t postpone the enforcement using the My Domain setting. Enhanced domains are required for production orgs and all remaining orgs in Spring ’23, starting in January 2023 for sandboxes and February 2023 for production orgs
The How – Enable: Enhanced Domains
Enable Enhanced Domains release update located in Setup > Release Updates.
The Impacts – Potential Impact of Enhanced Domains
When you enable enhanced domains, Salesforce URLs change across your org. Your production My Domain login URL doesn’t change, but almost every other Salesforce URL does. Experience Cloud sites, Salesforce Sites, Visualforce pages, and content files use your My Domain name. Domain suffixes (the part after the My Domain name) change to meet the latest security standards. Also, all sandbox URLs contain the word sandbox, making them easier to identify. Some examples listed below.
| URL Type | Enhanced Domain Format |
| Login | MyDomainName.my.salesforce.com |
| Content Files | MyDomainName.file.force.com |
| Experience Cloud sites | MyDomainName.my.site.com |
| Experience Builder | MyDomainName.builder.salesforce-experience.com |
| Salesforce Sites | MyDomainName.my.salesforce-sites.com |
| Visualforce pages | MyDomainName–PackageName.vf.force.com |
| Sandbox login | MyDomainName–SandboxName.sandbox.my.salesforce.com |
| Experience cloud sites in a sandbox org | MyDomainName–SandboxName.sandbox.my.site.com |
Because these changes affect so many URLs, they require multiple changes in Salesforce and with external settings.
Allowlist Changes
If your users have general access to the Internet, no action is required. If you control your users’ or servers’ access to the Internet through allowlists, you can optionally remove the domains that only apply to orgs without enhanced domains from your allowlist.
Firewalls & Proxy Servers
If you are using Firewall and Proxy Servers and filtering by hostname, you can optionally remove the hostnames that no longer apply to your org from your trust settings
Pinned Certificates
Salesforce doesn’t recommend certificate pinning. Consider updating your policies to exclude pinned certificates. Review Pinned Certs and make necessary changes if you need them still.
Sandbox Impacts
- API integrations into Sandboxes
Check whether the API client references the server endpoint. For the API client, use the metadataServerUrl or serverURL value returned by a login request. Don’t use a hard-coded server URL.
- Email templates for Sandboxes
Replace references to old URL with your new Enhanced Domain login URL.
- Multi-factor authentication (MFA) for Sandboxes
When your Enhanced Domain login URL changes, two multi-factor authentication (MFA) verification methods stop working: built-in authenticators and security keys. Before you deploy Enhanced Domain, work with users that have registered built-in authenticators or security keys for MFA to make sure that those users can continue to access Salesforce. - Identity Providers
Update your identity providers with your new Enhanced Domain login URL. Also update the enabled Authentication Services within the Authentication Configuration settings - Pardot
If your Pardot configuration uses the Pardot Connector User, update the login URL that Pardot uses. - SSO
Update all Single-Sign On (SSO) connections with new Enhanced Domain login URL
Public Sites Impacts
- Zones for Experience Cloud sites
Update the email notification URL. From Setup, in the Quick Find box, enter Zones, and then select Zones under Answers, Ideas Zones or Chatter Answers Zones. Then, next to the zone that you want to change, click Edit. To update the Email Notification URL, clear the existing URL so that the field is blank. Save the page, and the system populates the field with the new URL. - Custom Domain
Test external integrations that reference your custom domain, if any. If you serve the domain using a non-Salesforce host or service, review and update the domain configuration, such as CDN settings and hard-coded references to Salesforce URLs. If a custom domain such as https://www.example.com serves your Experience Cloud site, update to the target hostname used when forwarding requests from your domain’s proxy or CDN. - External Integrations
Update external integrations referencing your Experience Cloud sites and Salesforce Sites.
SSO. If you configured single sign-on (SSO) for your Experience Cloud sites, update the configuration. If you configured SAML SSO between your orgs and sites, update the configuration. If you configured a Salesforce authentication provider so that your users can log in to your custom external web app using their Salesforce credentials, verify your configuration. If your setup uses your site URL, update the configuration. - Mobile Publisher
After you enable enhanced domains, users that access an Experience Cloud site with the previous .force.com site URL from a web browser are automatically redirected to the new *.my.site.com site URL unless you disable those redirections.
Mobile Publisher for Experience Cloud Apps can perform this redirection in version 10.0 and later. If you’re running a version earlier than 10.0, upgrade to Mobile Publisher version 10.0 or later.
IP Restrictions
If IP restrictions are configured in Salesforce with only IPv4 addresses, users can see an error when they access your site that ends in *.my.site.com via IPv6 after you enable enhanced domains. To prevent that error, update your IP allowlists or restrictions to allow IPv6 source addresses for authorized users. In particular, review and update the login IP range restrictions for the relevant profiles, including the site’s guest user profile. - Update Public Facing Links
Update external-facing links such as publicly available Experience Cloud sites and Salesforce Sites. For example, a site URL can be used on your website, social media pages, marketing materials, and templates, such as email signatures and automated responses.
Update any hard-coded links to Experience Cloud sites and Salesforce Sites within your sites and custom pages. For example, if you host knowledge articles on an Experience Cloud site, update the URLs that include your *.force.com site URL. These links are redirected to the equivalent current site URL unless you disable the redirections. However, it’s a best practice to avoid hard-coded links. Use relative paths whenever you can. If your site URL changes again in the future, relative paths continue to work.
Refer to General Impacts -> Url Hardcoding in Code section to use tools to find hardcoded Urls
General Impacts
- Chatter
Tell your users to update all bookmarks listed on their Chatter groups. - Url Hardcoding in Code
Replace references to the org’s instance URL in Metadata and Data with Enhanced Domain URLs. Hardcoding urls should be avoided as best practice.
Use tools to Find Hardcoded Urls in Code
1. Log in to the Lightning Experience Configuration Converter, then select the Hard-Coded URLs tab.
2. If your org hasn’t been scanned for hard-coded URLs before, or if the scan data is out of date, scan to get the latest data.
3. Select all hard-coded URLs by clicking the select box in the header. Or, pick which URLs to move by selecting individual rows. You can always move the rest later.
4. Click Update Selected URLs.
5. A confirmation window appears that summarizes the steps we take after you confirm. While the update takes place, you can’t work in the other tabs. Salesforce emails you when updates are completed.
Search for hard-coded references with Salesforce Extensions for Visual Studio Code
The Salesforce Extensions for Visual Studio Code is a developer tool that can be leveraged to find hard-coded references. Follow the steps in the article, Creating a Salesforce Project in Visual Studio Code and Searching for Hard-Coded References, to update hard-coded references* in your org and your org’s metadata (setup or customer code).
How do I update hard-coded references in integrations?
For your integrations to Salesforce products or Force.com, use the Force.com API’s login() request as a starting point. The login() request should be sent to a generic endpoint, such as: https://login.salesforce.com/services/Soap/u/26.0.
The login() call will establish a Force.com session and respond with the login server URL. Set this server URL as the target server for subsequent API requests, and set the returned session ID in the SOAP header to provide server authorization for subsequent API requests.
myTrailhead
URLs for badge art stored in Salesforce changed. Update your modules and trails with the new badge art URLs.
If the URL for your enablement site’s login URL is an Experience Cloud site URL ending in *.force.com, that URL changes. To update your site’s authentication provider, contact Salesforce Customer Support.
Known Failures even with Enhanced Domain
Here are three specific situations where you can see a message about blocked cross-domain or third-party cookies, even when enhanced domains are enabled.
1. When you use a web browser other than Safari 13.1 or later or iOS 14 or later and the browser is configured to block cross-domain cookies, some Salesforce content can fail to load. This issue can occur on Visualforce pages and on Lightning pages with an embedded Visualforce page or embedded file-based content. In this case, the Visualforce page or file-based content can fail to load successfully and the browser displays an error message indicating that the web browser blocked the cookie. To resolve this issue, use Safari 13.1 or later, use iOS 14 or later, or allow cross-domain cookies in your browser.
2. When you access a page that contains an embedded Visualforce page, the embedded Visualforce page can display as a blank rectangle. This issue occurs in Salesforce Classic when you use a web browser that blocks cross-domain cookies, such as Safari 13.1 or later or iOS 14 or later. In Lightning Experience, the embedded Visualforce page displays correctly.
3. When accessing a Classic page in Lightning, you can receive a warning message about cross-domain cookies. This warning message occurs most often in Setup, because many Setup pages were built in Classic. To resolve this issue, click the link in the warning message to open the Setup page within a new tab or window.





