Loading

Salesforce Enhanced Domains FAQ

Publish Date: Mar 26, 2026
Description

Customer trust is our highest priority at Salesforce. To comply with the latest browser and security standards, Salesforce required that customers deploy enhanced domains in 2023. That feature updated the hostname formats for the domains that serve Salesforce orgs. 

In the Winter ’25 release (starting in August 2024), Salesforce stopped redirecting previous non-enhanced domains in sandboxes, Developer Edition orgs, patch orgs, scratch orgs, and Trailhead Playgrounds.

  • In the Spring ’26 release, which is deployed to production orgs starting in January 2026, Salesforce stops those redirections in all orgs via the Update References to Legacy Host Names release update, and you can’t reenable them.

Support ends for incorrect instanced URLs in API calls via the Update Instanced URLs in API Traffic release update. Salesforce enforces that change on a rolling basis in production orgs shortly after Winter ’27 deployment. 

This article was updated in July 2024 to focus on the most common questions about the end of those redirections. Previous questions about deploying and testing enhanced domains can be found in the “Archived Questions” section.

As always, you can use the revision history at the end of the article to track changes to this article.

Resolution

Frequently Asked Questions

Enhanced Domains Essentials

Redirections

Other Questions

 

ARCHIVED QUESTIONS

Get Started

Enable and Deploy Enhanced Domains

Update Your Org

Testing

URL (Hostname) Changes

Experience Cloud Sites & Salesforce Sites

Other Product- or Feature-Specific Questions

Other Questions

 

REVISION HISTORY

 


Enhanced Domains Essentials

What are enhanced domains?

Enhanced domains are the latest version of the My Domain feature. Because they meet the latest browser requirements, including allowing users to access Salesforce with browsers that block third-party cookies, they’re required in all Salesforce orgs. This feature was enforced in the Winter ’24 release, starting in September 2023 for production orgs.

Enhanced domains apply an org’s company-specific My Domain name to all URLs that Salesforce hosts for your org. This feature also changes domain suffixes (the part after the My Domain name) to meet the latest security standards. With no instance names, enhanced My Domain URLs are easier for users to remember and don’t change when an org is moved to another Salesforce instance.

For more information, see Enhanced Domains in Salesforce Help and the Enhanced domains video (available in English only).

 
How can I tell whether enhanced domains are deployed in my org?

See Determine Whether Enhanced Domains Are Enabled in Salesforce Help.

 


Redirections

Which URLs are redirected after enhanced domains are deployed?

After enhanced domains are deployed in an org, that org’s previous non-enhanced My Domain URLs are redirected, like with any My Domain change.

Here are some special considerations around redirections:

  • Because enhanced domains are tied to browser restrictions around third-party cookies, for the URLs related to that restriction that change with enhanced domains – such as Experience Cloud sites, Visualforce pages, and content URLs – accessing the old URL redirects to the new hostname until Salesforce stops those redirections.
  • The way a redirection works is that Salesforce sends a special redirect response to a request, telling the requester that the URL is no longer valid and to use the new URL. If the requester isn't configured to process that redirect response, the user or process isn't redirected. Thus calls to some of your old URLs can fail even with redirections in place. For this reason, we highly recommend that you test all integrations and calls to the URLs that changed.

These redirections are in place to help prevent disruption. We highly recommend that customers update all references to their old URLs after they deploy a new My Domain. One way you can find the places those old URLs are used is to temporarily disable redirections during your testing.

For more information on redirections, see My Domain Redirections in Salesforce Help.

 

I heard that Salesforce is stopping redirections for “legacy” or “non-enhanced” URLs. Which URLs are those?

For the list of URLs for which redirections stop and instructions on how to test for that change, see Prepare for the End of Redirections for Non-Enhanced Domains in Salesforce Help.

 

When do the redirections for non-enhanced (or legacy) URLs stop?

In sandboxes, Developer Edition orgs, demo orgs, patch orgs, scratch orgs, and Trailhead Playgrounds, redirections for legacy (non-enhanced) My Domain URLs stopped in Winter ’25, starting in August 2024.

In production orgs and demo orgs, legacy host name redirections end with the enforcement of the Update References to Legacy Host Names release update, which was introduced in Spring ’25. You can enable and disable those redirections until Spring ’26, which is deployed to production orgs starting in January 2026. In that release, Salesforce stops those redirections via the Update References to Legacy Host Names release update, and you can’t reenable them.

Also, if your org was created before October 2020, Salesforce stops redirections for hostnames that contain your instance name but not your My Domain name on the same schedule.

Finally, in Summer ’25, Salesforce introduced the Update Instanced URLs in API Traffic release update, which is enforced on a rolling basis shortly after Winter ’27. See End-of-Support Schedule for Incorrect Instanced URLs in API Traffic.

For more details on the schedule for the end of legacy redirections, see Enhanced Domains Timeline in Salesforce Help. To review the affected hostnames, see Prepare for the End of Redirections for Non-Enhanced Domains in Salesforce Help.

 

When do redirections end for old force.com site URLs?

Previous site URLs that end in *.force.com are no longer redirected in sandboxes, Developer Edition orgs, patch orgs, scratch orgs, and Trailhead Playgrounds with the Winter ’25 release, starting in August 2024. 

In production orgs and demo orgs, previous site URLs that end in *.force.com end with the enforcement of the Update References to Legacy Host Names release update in Spring ’26. For more details on the schedule for the end of legacy redirections, see Enhanced Domains Timeline in Salesforce Help.

 

Do redirections stop in API traffic, too?

Yes, redirections for legacy (non-enhanced) host names stop in Spring ’26 for API traffic. 

What this means: If you use an instanced URL (such as na45.salesforce.com when your org is currently on USA123) or an old login URL (for example, MyDomainName--SandboxName.my.salesforce.com instead of MyDomainName--SandboxName.sandbox.my.salesforce.com) in your API traffic, those URLs are no longer redirected. As a reminder, your org’s My Domain login URL didn't change with enhanced domains. 

The timing is slightly different based on the type of URL.

  • Winter ’25, starting in August 2024 – Legacy (non-enhanced) host name redirections stopped in all orgs except production and demo orgs.
  • Spring ’26, starting in January 2026 –  Redirections stop for legacy host names  in all other orgs, including production.
  • Winter ’27, starting in August  2026 (sandboxes) and September 2026 (production and all other orgs) – Support ends for incorrect instanced URLs in API traffic shortly after your org gets this release. see End-of-Support Schedule for Incorrect Instanced URLs in API Traffic.

To help you test for the end of support for instanced URLs in API traffic, Salesforce introduced a release update in Summer ’25. Look for Update Instanced URLs in API Traffic on the Release Updates page in Setup. To get notified about the specific rollout dates for that change, join the My Domain and Enhanced Domains Trailblazer Community Group

For more information, see Salesforce HelpEnhanced Domains Timeline.

 

Why did Salesforce delay the end of legacy redirections for production orgs?

Salesforce delayed their plan to stop redirections in production orgs twice. Both times, the delay was intended to give customers more time to test.

  • Initially, Salesforce delayed the end of redirections for legacy (none-enhanced) hostnames in production and demo orgs from Winter ’25 to Spring ’25. (In sandboxes, Developer Edition orgs, patch orgs, scratch orgs, and Trailhead Playgrounds, those redirections ended as scheduled in Winter ’25.)
  • In November 2024, Salesforce noticed that the volume of redirections for legacy hostnames in production orgs remained high. To prevent impact for our customers, we decided to postpone the end of legacy redirections for production and demo orgs one more time. 

To help you prepare for this change, Salesforce added the Update References to Legacy Host Names release update in Spring '25. That release update is enforced in Spring '26, which is deployed to production orgs starting in January 2026. Also, Salesforce plans to disable redirections for you in Summer '25 and in Winter ’26. For more information, see Enhanced Domains Timeline in Salesforce Help. 

 

Why did Salesforce delay the enforcement of the Update Instanced URLs in API Traffic release update?

That release update was initially scheduled to be enforced in sandboxes in Winter ’26 and in all other orgs, including production, in Spring ’26.

Salesforce delayed the enforcement of this release update twice:

  • In September 2025, when the planned enforcement in sandboxes uncovered a related issue with Visualforce pages returning a 404 error. After we resolved that issue, we scheduled enforcement in sandboxes starting in December 2025 and in all other orgs starting in February 2026.
  • In December 2025, Salesforce encountered an issue with the internal process to enforce this change across Salesforce instances. The enforcement is now scheduled to occur on a rolling basis shortly after orgs get the Summer ’26 release. 
  • Also in December 2025, Salesforce discovered that the previous issue can still affect a subset of orgs. We expect to resolve that issue in January 2026, so we recommend testing this change starting in early February 2026.

 

How can I disable legacy redirections in my production or demo org?

If Salesforce hasn't stopped redirections for legacy domains in your org, you can control those redirections via the Redirect legacy (non-enhanced) My Domain hostnames setting in the Redirections section of the My Domain Setup page. That setting is available only in production, demo orgs, and some new sandboxes. When Salesforce stops those redirections, that setting has no effect.

For more information, see Prepare for the End of Redirections for Non-Enhanced Domains in Salesforce Help.

 

Which redirections continue to work when the redirections for legacy URLs end?

If the hostname matches the formats in My Domain Login and Application URL Formats with Enhanced Domains in Salesforce Help, Salesforce redirects your previous My Domain hostnames until you deploy another My Domain change or until you disable or remove your previous My Domain. 

Incorrect instanced URLs in API traffic continue to work until the Update Instanced URLs in API Traffic release update is enforced.

For more information, see Understand Redirections for Previous My Domain Hostnames in Salesforce Help.

 

How can I tell when Salesforce stops redirections for my org’s legacy My Domains?

After enhanced domains were deployed, your previous non-enhanced hostnames are redirected. In sandboxes, Developer Edition orgs, demo orgs, patch orgs, scratch orgs, and Trailhead Playgrounds, those redirections stopped in Winter ’25, starting in August 2024.

Starting in October 2025, you could temporarily enable these redirections in a new sandbox. See the Winter ’26 release note, Test the End of Legacy Host Name Redirections in New Sandboxes.

In production, demo orgs, and sandboxes, redirections for those legacy URLs stop with the enforcement of the Update References to Legacy Host Names release update.  For more information, see Enhanced Domains Timeline in Salesforce Help. 

To learn the specific date that your org gets that release, navigate to Trust Status, search for your instance or My Domain name, and click the Maintenance tab. For more information, see Get Your Org Status and Upcoming Maintenance Dates with My Domain in Salesforce Help. 

 

How can I tell when incorrect instanced URLs stop working for API calls to my org?

That support ends on a rolling basis shortly after your org gets Summer ’26. To get notified about the specific rollout dates for that change, join the My Domain and Enhanced Domains Trailblazer Community Group.

Note: Although API traffic that uses your correct instanced URL continues to work after these changes, that API traffic stops working if your org’s instance changes. Your org’s instance name can change during regular maintenance, such as an instance refresh, or during a migration to the latest infrastructure, such as Hyperforce. For that reason, we recommend that you use your My Domain login URL in API calls.

For more information, see Enhanced Domains Timeline in Salesforce Help. 

 

 

How can I test what will happen when Salesforce stops redirections for non-enhanced domain URLs?

To help you test, in Winter ’25, Salesforce stopped legacy redirections in sandboxes, Developer Edition orgs, patch orgs, scratch orgs, and Trailhead Playgrounds. In production orgs and demo orgs, you can temporarily disable redirections from the My Domain page in Setup.

For details on My Domain redirections, the corresponding settings, and how to log redirections after a My Domain change, see My Domain Redirections in Salesforce Help.

For the list of legacy URLs and instructions on how to test for that change, see Prepare for the End of Redirections for Non-Enhanced Domains in Salesforce Help. 

 

How can I test what will happen when support ends for incorrect instanced URLs in API traffic?

To test the Update Instanced URLs in API Traffic release update, enable Block API traffic that uses an incorrect instanced URL in the Redirections section of the My Domain page in Setup. 

NOTE: If you enable that setting before the related known issue is resolved, SOAP login URLs via Visualforce pages can return a 400 Bad Request error. Salesforce plans to deploy a fix for that issue June 16–18, 2026, so we recommend that you test this change after June 18, 2026

For more information, see Prepare for the End of Redirections for Non-Enhanced Domains in Salesforce Help. 

 

How can I tell which URLs are being redirected?

Enable the Hostname Redirects event log. For more information, see Log My Domain Hostname Redirections in Salesforce Help.

 

Does redirection logging capture attempts to access a legacy domain that's no longer redirected?

Yes. The Hostname Redirects event log captures both successful and blocked redirections for the hostnames associated with the My Domain before the last My Domain deployment. It also captures successful and blocked redirections to legacy hostnames listed on Prepare for the End of Redirections for Non-Enhanced Domains in Salesforce Help.

In the log, the REDIRECT_REASON for redirections that were blocked because Salesforce stopped redirections for the legacy URL is Redirection was blocked because redirections for the legacy SOURCE_HOSTNAME are no longer supported.

  

I enabled redirection logging. How can I identify where the link lives that the user clicked before they were redirected?

Use the REFERRER and ORIGIN fields in the log, available in API version 58.0 and later. (API version 58.0 corresponds to the Summer ’23 release.)
 
Note
: The information contained in those fields is determined by the Referrer-Policy HTTP header sent with the request. So in some cases, these log fields can be null. For more information, see Object Reference for the Salesforce Platform: Hostname Redirects Event Type.
 
If those fields are null, you can also try these methods: 

  • Assess the volume of redirections for that URL. If the volume is typically low over a 24-hour period, weigh the effort of determining the origin against the potential impact.
  • If the redirected URLs include a managed package name, reach out to the package owner. For example, in a production org, these base URLs were previously used for items delivered by a managed package. Visualforce pages: MyDomainName--PackageName.visualforce.com and MyDomainName--PackageName.InstanceName.visual.force.com. Lightning container components: MyDomainName--PackageName.container.lightning.com. Visualforce pages and Lightning container components delivered by Salesforce use c as the package name.
  • To help users with bookmarks to legacy URLs, enable notifications during redirections before Salesforce ends those redirections. For more information, see Manage My Domain Redirections in Salesforce Help. 
  • To detect whether the call originated from within your org, you can also download your org's metadata and do a text search for the redirected hostname. However, that method can't identify the origin of requests made off-platform, for example from an API client, SSO party, external website, or browser bookmark.
  • Disable redirections so that the call errors out instead. This is particularly viable when testing in a sandbox.

In the end, you may not be able to identify the source of every redirection. We recommend that you focus on high-volume, high-impact areas and prepare to make some updates and help users when redirections end. 

 

My redirection log includes a bunch of calls to documentforce.com. Why are these still occurring? 

The documentforce.com domain is the legacy domain for files stored in Salesforce. Those can include images and PDF attachments. The new URLs end in .file.force.com. Often calls to these URLs are from a user’s bookmark, hard-coded references to images, or cached content. An example of a hard-coded reference is an image in an email template.

 

I believe that I removed all hard-coded references and external links to my legacy URLs. Why does my redirection log still show redirections?

The redirection log captures any call to your legacy URLs, including requests from bots. It’s an unfortunate reality that bots constantly crawl the internet, both to identify valid URLs and to attempt to find vulnerabilities. That kind of request is generally referred to as an “untargeted attack”. Also, other bots will make requests to known URLs, attempting to take advantage of known exploits. 

If you cleaned up the logged redirections that you could identify, searched for and removed hard-coded references, and tested Salesforce with redirections disabled – including integrations – that’s the best way to ensure that you’re prepared for the end of legacy redirections. 

 

I have redirections enabled. Why am I still getting errors for some connections?

The way a redirection works is that Salesforce sends a special redirect response to a request, telling the requester that the URL is no longer valid and to use the new URL. If the requester isn't configured to process that redirect response, the user or process isn't redirected. For this reason, calls to some of your old URLs can fail even with redirections in place. For this reason, we highly recommend that you test all integrations and calls to the URLs that changed.

 

Why am I seeing messages about redirections in Setup?

If Setup pages for your org aren't served on the salesforce-setup.com for your org and the My Domain setting Require first-party use of Salesforce cookies is enabled, accessing older Setup pages that were built in Classic requires an extra step. Users see a message that directs them to open the page in Salesforce Classic.

Salesforce is rolling out the new setup domain (salesforce-setup.com for Setup pages). When your Setup pages are served on that domain, the message will no longer appear. 

For more information on the new salesforce-setup.com domain, see this documentation:

 

The 'Redirect previous My Domain URLs to your current My Domain' option is missing in my org.

That option is available only after you deploy a change to your My Domain. Otherwise, there are no previous My Domain URLs to redirect.

The other reason this option can be unavailable is if you deployed a change and then clicked Remove Previous My Domain. (Like the checkbox, that button is only visible after you deploy a change to your My Domain.)

 

 


Other Questions

 
What’s the difference between enhanced domains and partitioned domains?

With Partitioned Domains, My Domain hostnames for your Developer Edition org, demo org, patch org, sandbox, scratch org, or Trailhead Playground include a word related to the org type. For example, partitioned domains for Developer Edition orgs include the word develop. Partitioned domains allow Salesforce to maximize the availability of your orgs by gradually rolling out delivery changes. And it’s easier to identify an org by a URL when the domain is partitioned. Partitioned domains are used by default in qualifying new orgs (of the types listed above). They’re not required in existing orgs, and they aren’t for production orgs.

Enhanced Domains are the current version of My Domain that meets the latest browser requirements. Sandboxes with enhanced domains are always partitioned. (They include the word “sandbox”.) Sandboxes are only partitioned through enhanced domains; you can’t enable partitioned domains in a sandbox without enhanced domains, and you can’t disable partitioned domains in a sandbox with enhanced domains. Enhanced domains were enforced in Winter ’24 and can’t be disabled. 

 
I still have questions. How can I get help?

For general questions, join our monitored My Domain and Enhanced Domains Trailblazer Community group. You can search for answers and post new questions in that group.

For time-sensitive questions and issues, submit a case to Salesforce Customer Support.

 

 


Archived Questions

These questions are no longer relevant when enhanced domains are enforced.

Get Started

I’m confused about enhanced domains. Where should I start?

We know that there's a lot of information out there on this feature, and that the feature itself is complex.

The Enhanced domains video  (available in English only) provides an overview of the feature, the deployment and enforcement timeline, the impact, and where to start. More information is also below.

The best place to start is usually determining what the impact is for you. To do that, we recommend you start with these pages in Salesforce Help. (Note that the impact isn't based on the Salesforce edition you use, but rather which functionality you use.)

    • Determine the Required Authentication Updates After a My Domain Change - will help you do just that: determine if you have any authentication configured for your org. If you do, the page details which instructions to follow.
    • Example My Domain Change Pre-Deployment Checklist and Example My Domain Change Post-Deployment Checklist - these checklists include the steps every customer may need to take. We emphasize the word "may" because not every customer uses every feature. To figure out the steps you need to take, you can use these checklists and remove the items that don't apply to your configuration. In particular, every customer should check to see if they use allowlists or have configured firewalls or proxy servers and update those as needed. (If you're not sure, check with your information security or networking folks.)
    • Update Your Org for My Domain Changes - warning: this is a VERY dense page, so take a breath first. We are keeping everything in one place for ease of use, but we also know that can be overwhelming. This page aligns with the pre- and post-deployment checklists, providing more details on what to do if a step applies to you. Be sure to read the descriptions above the tables, because it's possible that you can skip a table or two.
    • Test My Domain Changes - lists the high-level steps of what to test. 

Useful reference:

    • My Domain Hostnames - this details the hostnames that Salesforce can serve for your org, and the corresponding functionality. This can help you determine which functionality you use.
    • My Domain Login and Application URL Formats Without Enhanced Domains - lists all the URLs that change with enhanced domains (focus on the production list to start). You'll only care about the types that apply to you (which you just identified by looking at the hostname list).

Whew! That's a lot of information. You can also view these previous webinars:

    • March 2022 webinar, “Prepare for Enhanced Domains” recording and deck
    • July 2022 webinar, “Enhanced Domains Enforcement: June 2022 Updates and Authentication Deep Dive” recording and deck.

We also encourage customers to join the monitored My Domain and Enhanced Domains group in the Trailblazer Community.

  

What was the timeline for enhanced domains? When were enhanced domains deployed and enforced?

The Deploy Enhanced Domains (formerly "Enable Enhanced Domains") release update was first made available with the Summer ’21 release.

Enhanced domains were enforced in phases starting in Winter ’23.

    • Winter ’23 (starting in August 2022): Enhanced Domains deployed in sandboxes and non-production orgs, with options to opt out & disable the feature. Non-production orgs include demo orgs, Developer Edition orgs, free orgs, patch orgs, Trailhead Playgrounds, and trial orgs. 
    • Spring ’23 (starting in January 2023): Enhanced domains deployed in all orgs that don’t have enhanced domains deployed, with options to opt-out & disable the feature. 
    • Summer ’23 (starting in June 2023): Enhanced domains deployed in all orgs that don’t have enhanced domains deployed, with an option to disable the feature.
    • Winter ’24 (starting in August 2023): Enhanced domains enforced in all orgs.

For additional timeline details, see Enhanced Domains Timeline in Salesforce Help.

  

How can I prepare for enhanced domains?

Because enhanced domains affect all application URLs, we recommend that you test and deploy enhanced domains before this change is enforced. We also recommend that you test enhanced domains in a sandbox before you update production. 

For details on how to set up, test, and deploy enhanced domains, see Plan for a My Domain ChangeEnhanced Domains and Update Your Org and Test My Domain Changes in Salesforce Help.

 

Are there checklists to help me deploy enhanced domains?

For example project, pre-deployment, and post-deployment checklists, see Example My Domain Change Checklists in Salesforce Help. Those checklists are also available in Quip in My Domain Change Checklists Templates

A couple of notes on the checklists:

    • They're available in English only. The Help content will be localized with the Spring ’23 release.
    • It’s unlikely that every step in the checklists applies to you. The checklists include the possible steps for all Salesforce configurations. Pare down the templates to match your project. For example, if Experience Cloud sites (formerly Communities) aren't enabled, remove those steps when you create your personal checklists. Similarly, there’s a section on whether your My Domain login URL changes. If you don’t rename your My Domain or change your domain suffix in production, that section doesn't apply when you deploy enhanced domains.
    • For more details on the pre-deployment and post-deployment tasks, see Update Your Org for My Domain Changes  in Salesforce Help. 

 
 
Where can I get more information on enhanced domains?

For details about the change being enforced, see the Summer ’23 Release Note: Deploy Enhanced Domains (Release Update), and check out the Enhanced domains video (available in English only). 

For details on how to set up, test, and deploy enhanced domains, see Plan for a My Domain ChangeEnhanced Domains and Update Your Org and Test My Domain Changes in Salesforce Help. 

You can also view these previous webinars:

    • March 2022 webinar, “Prepare for Enhanced Domains” recording and deck
    • July 2022 webinar, “Enhanced Domains Enforcement: June 2022 Updates and Authentication Deep Dive” recording and deck.

We also encourage you to join the monitored My Domain and Enhanced Domains group in the Trailblazer Community.

 

Enable and Deploy Enhanced Domain

 
How do I enable and deploy enhanced domains?

Important: Don't get locked out! Before you deploy enhanced domains, understand whether your My Domain login URL changes and make sure that you can log in after the change. For details, see Preserve Login Access During a My Domain Login URL Change in Salesforce Help.

In Setup, on the My Domain page, edit My Domain Details and select Use enhanced domains. Then, after Salesforce provisions your new My Domain, deploy your new My Domain from the same Setup page.

For details on how to set up, test, and deploy enhanced domains, see Plan for a My Domain ChangeEnhanced Domains and Update Your Org and Test My Domain Changes in Salesforce Help.



What does the "network doesn't allow you to access these domains" message mean? And why did it disappear?

As part of the provisioning process for your new domain, Salesforce performs a cursory check to ensure that you have network access to the new domains. If you don’t have the required access, the My Domain page lists the URLs you can’t access in red. To prevent potential access issues, you can't click the Deploy New Domain button.

The access issues can be temporary or they can require action.

    • Temporary network issues can stem from incomplete DNS registration, incomplete DNS propagation, or a stale DNS cache. These issues usually resolve without action within 10 minutes. The warning message disappears upon the first visit to the My Domain page after the temporary issue is resolved.
    • If the message doesn't disappear after you wait 15 minutes before you revisit the My Domain page, review your allowlists or network configuration. In addition to allowlists, verify your firewall and proxy server configurations to ensure that you have allowed the required domains. Tip: If you’re unsure whether your company or network uses these methods, check with your IT or Information Security (InfoSec) department.


To deploy your My Domain, revisit the My Domain Setup page after the access issues are resolved.

 

Update Your Org

What updates do I need to make in my org when I enable and deploy enhanced domains?

At a high level, update references to your changed URLs.

When you enable enhanced domains, all URLs across your org contain your company-specific My Domain name, including Experience Cloud sites and Salesforce sites. Because your org’s URLs change, we recommend that you test your org’s functionality in a sandbox with enhanced domains before enabling this feature in production. Pay particular attention to customizations that reference your old URLs. 

For a list of the areas to update, see Update Your Salesforce Org for Your New Domain in Salesforce Help. For guidance on planning for this change and example checklists, see Plan for a My Domain Change in Salesforce Help.

The change to external-facing URLs such as Experience Cloud sites and Salesforce sites deserves additional attention. These changes can require updates to your external-facing links and the configuration of any custom domains pointing to these URLs. For more information, see Considerations for Enhanced Domains in Salesforce Help.After you enable enhanced domains, test. Salesforce recommends that you test enabling enhanced domains in a sandbox to identify the updates to make when you deploy a My Domain in production. For more information, see Test Your New My Domain in Salesforce Help.

 
How can I identify customizations that reference the old domains in my org?

One method is to download your org's metadata and search for occurrences of old URLs. For a list of URLs to search for, see My Domain URL Format Changes with Enhanced Domains Deployment in Salesforce Help. To search your Salesforce code, download the metadata. Then use a command-line interface such as Salesforce CLI

Depending on how unique the instance name or My Domain name is relative to the rest of the metadata, searching for the org's instance name (when deploying a My Domain) or My Domain name (when enabling enhanced domains) can be easier.

 
What updates do I need to make to SSO, MFA, and other authentication methods?

Depending upon your configuration, you may need to make updates before and after you deploy enhanced domains. To determine whether you need to make any updates to your authentication configuration and understand the steps to take, see Update Authentication After a My Domain Change in Salesforce Help. 

 

How can I restore the authentication providers on my login page?

If your users can authenticate with alternate identity providers or a SAML Single Sign-On (SSO) authentication method from your My Domain login page or Experience Cloud site login page, those authentication methods stop working when the page's URL changes and can be removed from the page.

To restore these authentication methods:

    1. For each authentication method, update the corresponding authentication service.
    2. Verify the authentication method on the login page. If necessary, add the authentication providers to your login page again. See these topics in Salesforce Help:

 

Testing


How do I test enhanced domains?

After you Update Your Org for My Domain Changes, follow the guidance on Test My Domain Changes in Salesforce Help. Note that Salesforce highly recommends that you temporarily disable all redirections before you test. 

 
What are some common issues that arise after deploying enhanced domains?

Here are some common themes for issues that you can encounter after you deploy enhanced domains.

NOTE: This is not a comprehensive list of the issues that can arise. We recommend testing enhanced domains in a sandbox to verify your configuration before you deploy enhanced domains in production.

When you deploy enhanced domains in production without renaming your My Domain or changing your My Domain suffix, these issues that can arise.

BehaviorRelated Updates
Errors when attempting to access Salesforce pages, including but not limited to: Experience Cloud sites, Salesforce Sites, Visualforce pages, and content. Update your Allowlists, trusted domains, permitted domains, and other hostname-based restrictions.
Update hard-coded references to your old URLs.
Update your version of the Mobile Publisher for Experience Cloud app.
Users can't access Experience Cloud sites or Salesforce Sites.Update IP-based restrictions to include the IPv6 range.
Update authentication (SSO, MFA, named credentials).
Update the identity providers on your login page.
Update hard-coded references to your site URL.
Update trusted domains for inline frames.
Update network-level restrictions that specify only IP addresses.
Your custom domain that serves your Experience Cloud site or Salesforce Sites stops working.Update the domain configuration as required.
Open CTI (Computer Telephony Integration) or Click to Dial stops working.Update your telephony provider and Open CTI. For more information, see the Knowledge Article, Enhanced Domains and Open CTI with Visualforce (Spring ‘23).
Integrations, external software, or connected apps can't access your Experience Cloud sites or Salesforce Sites.Update authentication to use your new site login URL.
Work with the third party to update their configuration to use your new site login URL.
Work with the third party that to ensure that they support Server Name Indication (SNI).
External software and connected apps can't access your sites.Update authentication to use the new site login URLs.
Users can't access Enablement Sites (myTrailhead) that uses your sites URL that ends in *.force.com.Contact Salesforce Customer Support to update your authentication provider with your new sites login URL.
Images stored in Salesforce fail to load on both external and internal pages.Update the URL references to content stored in Salesforce.
Update badge and image URLs in Enablement Sites (myTrailhead)
Some functionality within installed packages from AppExchange stops working.  Verify whether the package has been updated and install a patch or version that supports enhanced domains.


When you deploy enhanced domains in a sandbox, or deploy enhanced domains in a production org and also change your My Domain name or suffix, your My Domain login URL also changes. Thus you can encounter the issues listed above and these additional common issues. 

BehaviorRelated Updates
Users and processes can't access your Salesforce org.Update authentication (SSO, MFA, named credentials).
Update the identity providers on your login page.
Update hard-coded references to your My Domain login URL.
Third-party connected apps and integrations fail to connect to your org or site.Update authentication.
Update hard-coded references to your My Domain login URL.
Ensure that third parties can process the redirect header from Salesforce.
A Messaging for Web deployment that was previously published no longer appears to your customer. Republish all pre-existing deployments of Messaging for In-App.
Users can't access Enablement Sites (myTrailhead) that uses your My Domain login URL.Contact Salesforce Customer Support to update your authentication provider with your new My Domain login URL.
Service Cloud Voice stops working.Work with your telephony provider to update your configuration with your new URLs.
Update the allowlist in Amazon Connect with your new Visualforce URL. 
Note: When you deploy enhanced domains in an org on Spring ’23, Salesforce updates Amazon Connect except for the allowlist.

For more information on the related updates, see Update Your Org for My Domain Changes  in Salesforce Help.
 

URL (Hostname) Changes

Do enhanced domains affect instanced URLs in the form <instanceName>.salesforce.com?

Enhanced domains have no impact on instanced URLs in the format <instanceName>.salesforce.comHowever, we recommend against using those URLs, because they can change with an org migration, which is part of regular maintenance. Also, API calls to a Hyperforce org can’t use that method.

If you find instanced URLs during your updates for enhanced domains, we highly recommend that you use one of the following:

    • your org's My Domain login URL, available on the My Domain Setup page.
    • the generic Salesforce login URL: login.salesforce.com for production orgs and test.salesforce.com for sandboxes.

For more information, see Log In to Salesforce with Code in Salesforce Help.

If you find another URL that contains your instance name, enhanced domains probably changed that URL. For more information, see My Domain URL Format Changes with Enhanced Domains Deployment and Prepare for the End of Redirections for Non-Enhanced Domains in Salesforce Help.   

 

What’s the impact of enhanced domains on orgs that use the cloudforce.com or database.com suffix?

If your org is served by URLs with the *.cloudforce.com or *.database.com suffixes, you must move to the Standard (*.my.salesforce.com) My Domain suffix before you can enable enhanced domains. Thus, when enhanced domains are enforced, you will also move to the *.my.salesforce.com suffix.

This means:

    1. When you enable enhanced domains, you must select Standard in the Domain Suffix field. Only then can you select Use enhanced domains.

    2. Your login URL changes in production (because the suffix changes). When you plan to deploy enhanced domains and update your org, follow the steps related to when your My Domain login URL changes. 

After you deploy enhanced domains, your previous *.cloudforce.com or *.database.com URLs are redirected until you deploy another My Domain or until Salesforce stops those redirections, whichever comes first. For more information, see My Domain Redirections in Salesforce Help.

 

Does the URL for my branded login page on cloudforce.com change with enhanced domains?

If your users log in to Salesforce via a branded login page on the .cloudforce.com domain, the branded login page remains available. After the user logs in, Salesforce serves your org on the enhanced domain URLs.


 
Do enhanced domains prevent users or APIs from using the standard login URLs?

No. Deploying enhanced domains doesn’t prevent users or APIs from logging in with login.salesforce.com (for production orgs) or test.salesforce.com. After you enable enhanced domains, you can control this behavior with two options in the Policies section of the My Domain Setup page. For more information, see Set My Domain Login and Redirect Policies in Salesforce Help. For more information on all the options related to My Domain hostnames, see Understand Redirections for Previous My Domain Hostnames in Salesforce Help.

To add an extra layer of security, Salesforce recommends that you use your org’s My Domain login URL instead of login.salesforce.com or test.saleforce.com to log in to Salesforce with code and APIs. For more information, see Log In to Salesforce with Code in Salesforce Help.


Do enhanced domains impact existing API integrations?

To determine whether an API integration is impacted when you deploy enhanced domains, look at the URL that the integration uses to connect to Salesforce. If that URL changes, the integration can stop working until you update the URL. For a list of the URLs that change when you deploy enhanced domains, see My Domain URL Format Changes with Enhanced Domains Deployment in Salesforce Help. Although your previous URLs are redirected by default, not every third party can process those redirections. More importantly, Salesforce stops some redirections in Winter ’25 and Spring ’25, so be sure to update API integrations that rely upon the old URL.

More information:

In a sandbox, your My Domain login URL (https://MyDomainName--SandboxName.my.salesforce.com) changes when you deploy enhanced domains: the word "sandbox" is added to it.

    • Existing API integrations that use your sandbox My Domain login URL can stop working after you deploy enhanced domains. Update the integration to use the new format (https://MyDomainName--SandboxName.sandbox.my.salesforce.com).
    • Existing API integrations that use the generic https://test.salesforce.com URL continue to work when you deploy enhanced domains unless the My Domain option, Prevent login from https://test.salesforce.com, is enabled.

In production, your My Domain login URL (https://MyDomainName.my.salesforce.com) doesn't change when you deploy enhanced domains unless you also change your My Domain name or suffix.

    • Existing API integrations that use the generic https://login.salesforce.com URL continue to work when you deploy enhanced domains unless the My Domain option, Prevent login from https://login.salesforce.com, is enabled.
    • If you deploy enhanced domains without changing your My Domain name or suffix in production, API integrations that use your My Domain login URL continue to work.
    • If you change your My Domain name or suffix as part of deploying enhanced domains, your My Domain login URL changes, and API integrations that use your My Domain login URL can stop working until you update the API integration to use the new login URL.

In both sandboxes and production, if an API uses your *.force.com Experience Cloud site or Salesforce Site URL, those URLs change with enhanced domains. Update the API to use the new site URL after you deploy enhanced domains. 

If the API integration uses any other URL to integrate with Salesforce, check the URL format; it probably changes when you deploy enhanced domains.

 

Do enhanced domains affect my lightning URLs?

When you deploy enhanced domains in production: 

    • There is no change to URLs with the MyDomainName.lightning.force.com hostname format
    • URLs with the MyDomainName--PackageName.container.lightning.com hostname format change
    • URLs with the InstanceName.lightning.force.com hostname format change

When you deploy enhanced domains in a sandbox, all of the corresponding URLs change:

    • URLs with the MyDomainName--SandboxName.lightning.force.com hostname change (the word "sandbox" is added)
    • URLs with the MyDomainName--SandboxName--PackageName.container.lightning.com hostname format change 
    • URLs with the InstanceName.lightning.force.com hostname format change

For more information, see My Domain URL Format Changes with Enhanced Domains Deployment.

  
Do I need to update hardcoded URL references in managed or installed Visualforce pages?

If you own the Visualforce page, yes, you must update any hardcoded URL references in the page, ideally using a relative or dynamically created URL instead. However, keep in mind that you probably can't edit Visualforce pages delivered by a package directly because the page is managed by the package. (And even if you can update it, you don't want your changes to be overridden by the next package update.)

For managed packages, Salesforce highly recommends that package developers use relative paths to build any links. If the package developer used that approach, the link should work after you enable enhanced domains. 

We recommend that you testing those pages in a sandbox with enhanced domains enabled and redirections (temporarily) disabled. If you find an issue, contact the package developer so that they can publish a new version of their package that works with enhanced domains.

For more information, see Link to Salesforce Domains in Packages in Salesforce Help and Call Salesforce URLs Within a Package in the ISVForce Guide. (Tip: the second page provides examples of building dynamic URLs that apply to more than packages.)

 
Can I change the suffix of My Domain through enhanced domains?

No, you can't change the suffix of the URLs that Salesforce hosts for your org with enhanced domains.* Enhanced domains aren’t about customizing URLs. This feature affects internal Salesforce suffixes only. It’s required for compliance with browser standards and prevents disruption when your org is moved to another Salesforce instance. You can read about the impacted URLs here.

To serve an Experience Cloud site or Salesforce Site using a custom domain that you own, such as https://www.example.com, see Custom Domains in Salesforce Help.

* If your My Domain login URL ends in *.database.com or *.cloudforce.com, you must adopt the standard *.my.salesforce.com suffix as part of deploying enhanced domains.  

 
Can I combine renaming my org’s My Domain name with enabling enhanced domains?

Yes! In fact, we recommend combining these two changes. If you want to rebrand the URLs that Salesforce hosts for your org, you can combine the updates and testing for a My Domain name change and enabling enhanced domains. To make the changes together, update the My Domain name value and select the enable enhanced domains setting on the My Domain Details page and save it as one change to be provisioned and deployed.

In addition to one round of testing, this also means one change for your end-users. Most importantly, this is the best way to preserve the redirections from your Salesforce org’s current URLs. If you change your My Domain more than one time, only the last set of My Domain URLs for your org are redirected. So if you enable enhanced domains and then change your My Domain name, your original Salesforce org URLs (before the two changes) aren’t redirected.

 

Experience Cloud Sites & Salesforce Sites

How do enhanced domains affect my site URL?

Enhanced domains use a My Domain-based hostname for Salesforce Sites and Experience Cloud sites instead of force.com-based hostnames, and sandbox URLs contain the word “sandbox”. This doesn't apply to custom domains, which continue to be preferred. Using a custom domain, such as www.example.com, is recommended. For more information on custom domains, see Custom Domains in Salesforce Help.

Example Salesforce URLs without enhanced domains in an HTTPS non-sandbox org:

    • Salesforce Sites: https://SalesforceSitesSubdomain.secure.force.com
    • Experience Cloud sites: https://ExperienceCloudSitesSubdomainName.force.com

Example Salesforce URLs with enhanced domains in an HTTPS non-sandbox org:

    • Salesforce Sites: https://MyDomainName.my.salesforce-sites.com
    • Experience Cloud sites: https://MyDomainName.my.site.com

A full comparison is documented in Salesforce Help. See My Domain URL Format Changes with Enhanced Domains Deployment.

For details on the updates you may need to make to your sites when you deploy enhanced domains, see Update Your Org for My Domain Changes in Salesforce Help.

 
 
Can I keep my old *.force.com site URL?

No. The *.force.com site URLs aren't compatible with third-party cookie blocking. Enhanced domains change the Salesforce-hosted URL structure to solve for this.  

 
Can I customize the format of my site URL?

Yes. Use a custom domain. A custom domain is a domain that you own, such as https://www.example.com, that you use to serve your site. For more information, see Custom Domains in Salesforce Help. Salesforce highly recommends custom domains.

 
I serve my site with a custom domain. Do I need to make any changes to that domain when I deploy enhanced domains?

Yes, although there are fewer steps than if users access your site via a *.force.com domain. Most importantly, you don't need to update your domain in Salesforce Setup. Your custom domain uses your new Salesforce-hosted site URL automatically.

When you deploy enhanced domains, work with third parties that integrate with your org to ensure that they support SNI. There are also a few potential steps to take based on how your custom domain is configured. For more information, see Update Your Org for My Domain Changes in Salesforce Help.

 
Do enhanced domains affect the CNAME of my custom domain?

No. Enhanced domains don't change the live.siteforce.com hostnames. Custom domains using live.siteforce.com continue to function as before when you enable enhanced domains.

 

After deploying enhanced domains, some users can’t access my Experience Cloud site.

To understand the reason that the user can't access the site, review the user's login history.

If the login history reflects an IP restriction: 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.

If you wish to add IP ranges that cover the entire IPv4 and IPv6 Internets, add these ranges:

:: to ::fffe:ffff:ffff
0.0.0.0 to 255.255.255.255
::1:0:0:0 to ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff

For more information on setting IP restrictions Salesforce, see Network Access, Session Settings, and Profile-based IP restrictions.

If the user is experiencing authentication issues, see Update Your Org for My Domain Changes in Salesforce Help.

Review potential domain restrictions. For Experience Cloud sites verify that *.my.site.com is allowed.

For more information, see the Knowledge Article, Restore Access to Sites After Enhanced Domains Auto-Deployment  

 

How do I know if I have an IP allowlist or pinned certificates?

Both IP allowlists and pinned certificates are methods of restricting the traffic that is allowed into your network or to connect to your servers.  They're not Salesforce features, but someone at your organization may use them to secure your network. If you’re unsure whether your company or network uses these methods, check with your IT or Information Security (InfoSec) department.

An Internet Protocol (IP) allowlist includes the addresses that are allowed to access the network. Connections from IP addresses not on the list are rejected. For the list of IP addresses to allow, see the Salesforce Knowledge Article, Salesforce IP Addresses and Domains to Allow.

For the areas within Salesforce where you can restrict access by IP address, see Network Access, Session Settings, and Profile-based IP restrictions.

At a very high level, certificate pinning restricts which certificates are considered valid for a website. The website can have multiple valid certificates, but certificate pinning only lets you connect using some of them. Generally speaking, Salesforce doesn’t recommend certificate pinning. If your company requires the use of certificate pinning, check to see which type of pinning is used. Salesforce doesn’t recommend pinning leaf certificates.  
 

Users see an SSL connection error after I updated my custom domain to point to my new site URL

After I updated my custom domain's proxy or CDN to point to the new site URL ending in *.my.site.com or *.my.salesforce-sites.com, users see an SSL connection error.

Example format of the error:
SSL Connection Error
Error 26
[custom domain URL]
[time stamp ]
What happened?
The proxy failed to connect to the web server, SSL connection failed.

This error indicates an issue completing a valid SSL handshake with the origin server. 

The most common cause that we've seen for this issue is an update of the Host HTTP header value or proxy server to point to the MyDomainName.my.site.com  or MyDomainName.my.salesforce-sites.com URL. To use an external  option, configure your proxy or CDN service so that the requests sent to Salesforce contain the originally requested Host HTTP header instead. For 

Troubleshooting steps:

 

 

Other Product- or Feature-Specific Questions

​​​​​Do enhanced domains affect the URLs for my published knowledge articles?

If your knowledge article links use the *.lightning.force.com or *.my.salesforce.com domain, those domains don't change in production orgs when you deploy enhanced domains. In a sandbox, the word “sandbox” is added to those URLs.

If your knowledge article uses your Experience Cloud site *.force.com URL, the knowledge article uses your new *.my.site.com URL, and you must update all hard-coded references to those URLs.

 
How do enhanced domains affect Account Engagement?

If your Account Engagement configuration uses the Connector User and your org's login URL changed, the login URL that Account Engagement uses behind the scenes must be updated. To force this update, within Account Engagement, update the Connector User. You can use the same user, but you must save the user again in Account Engagement. Then log out and back in to your org to complete the process.

If you’re using the Account Engagement Integration User, no changes are needed.

Note: No change to the Account Engagement tracker domain configuration is required when you deploy a My Domain or enable enhanced domains. Likewise, no change to the Connector User is required if you enable enhanced domains on an existing My Domain, because that doesn’t change the login URL.

As with all features, we recommend that you test in a sandbox environment. In particular, look for hard-coded URLs. For more information, see the Knowledge Article, Updating Hard-Coded References. For more information on the various areas to update in your org, see Update Your Salesforce Org for Your New Domain in Salesforce Help.
 

How do enhanced domains impact enablement sites (myTrailhead)?

There are two possible areas of impact: the enablement site (myTrailhead) login URL and their badge art.

Badge Art
When you deploy enhanced domains, the URLs for content (files) stored in Salesforce change. If your badge art is stored in Salesforce, update your modules and trails with the new badge art URLs. For more information, see Configure Your Enablement Site in Salesforce Help.

Enablement Sites (previously myTrailhead) login URL
When you configure enablement sites, you have the option to use your My Domain login URL or site URL as your enablement site (myTrailhead) login URL. 

    • If you used your *.force.com site URL as your enablement site login URL, the *.force.com URL changes with enhanced domains. Contact Salesforce Customer Support to update your enablement sites (myTrailhead) login URL after you deploy enhanced domains.
    • If you used your My Domain login URL as your enablement site login URL, that URL changes when you deploy enhanced domains in a sandbox. That URL also changes when you deploy enhanced domains in production org and also change your My Domain name or suffix. If that URL changed, contact Salesforce Customer Support to update your enablement sites (myTrailhead) login URL after you deploy enhanced domains.

 
 
Do enhanced domains change the URL for Web-to-Lead?

The webto.salesforce.com hostname remains the same with and without enhanced domains.


I develop packages for AppExchange. What changes do I need to make to my managed package to make it work with enhanced domains?

For information on updating your package to use the System.DomainCreator Apex class, see Link to Salesforce Domains in Packages in Salesforce Help and Call Salesforce URLs Within a Package in the ISVforce Guide.

For details on enhanced domains and how to enable the feature, see Enhanced Domains in Salesforce Help and these two webinars:

    • March 15, 2022 - Prepare for Enhanced Domains. Recording and Deck.
    • July 13, 2022 - Enhanced Domains Enforcement: June 2022 Updates and Authentication Deep Dive. Recording and Deck.

   

Other Questions

What’s the recommended order for adopting MFA, enhanced domains, and Hyperforce?

For the recommended adoption order, benefits of each enhancement, and where to get more information on each of these enhancements, see the Knowledge Article, Recommended Adoption Order for MFA, Enhanced Domains, and Hyperforce.

  
Who sees the banner about enhanced domains? And how can I make the banner go away?

If enhanced domains aren’t deployed and Salesforce deploys the feature with Spring ’23, admins see the banner when they log in. If the option Automatically deploy enhanced domains with Spring ’23 is disabled, the banner no longer displays.

To close the banner in Lightning Experience, an individual user can click the X. The banner is persistent in Salesforce Classic. 

For the announcement about the banner, see the Winter ’23 Release Note: Other My Domain Changes.

 

Does enabling enhanced domains change the IP range for the org?

No, enhanced domains do not change the IP range for the org. However, an eventual Hyperforce upgrade for the org will essentially remove support for IP address allowlists. We do not recommend using IP allow-listing. We recommend that you read this article; especially the first several paragraphs, and move toward allowing the required domains.  

 


Revision History

DateRevision
November 22, 2022Initial article publication
November 29, 2022Added two questions:
December 5, 2022Added How do enhanced domains impact enablement sites (myTrailhead)?
December 7, 2022Minor updates to What are some common issues that arise after deploying enhanced domains? 
December 17, 2022Added links to the Enhanced domains video  (available in English only).
December 19, 2022Added Do enhanced domains impact existing API integrations?
January 9, 2023
January 18, 2023Added What’s the recommended order for adopting MFA, enhanced domains, and Hyperforce?
January 23, 2023Added How can I restore the authentication providers on my login page?
January 25, 2023Added Enhanced domains are already enabled in my org. Who did that? And does that mean that I'm done?
February 18, 2023
March 3, 2023Updated If I find an issue during testing, can I disable enhanced domains? Added a link to the KA Disable Enhanced Domains.
March 15, 2023Updated After deploying enhanced domains, some users can’t access my Experience Cloud site
  • Update the question to refer to deploying enhanced domains instead of enabling them.
  • Added a link to another Knowledge Article on troubleshooting site access after enhanced domain deployment.
Updated What are some common issues that arise after deploying enhanced domains?: added network-level restrictions that rely only on IP addresses to the list of possible causes for Experience Cloud site access issues.
April 28, 2023Updated What's the impact of enhanced domains on orgs that use the cloudforce.com or database.com suffix? to clarify that those URLs are redirected like other previous My Domain URLs.
May 15, 2023Added I enabled redirection logging. How can I identify where the link lives that the user clicked before they were redirected?
June 26, 2023
October 23, 2023Updated Will my old URLs be redirected? to reflect that we use 307 redirect codes, not 308.
July 12, 2024
August 7, 2024

Added the question, Does redirection logging capture attempts to access a legacy domain that's no longer redirected?

Updated the following questions to reflect the new timeline for the end of redirections for legacy (non-enhanced) domains.

Updated all links to My Domain URL Format Changes When You Enable Enhanced Domains to reflect the updated Help topic title in Winter '25, My Domain URL Format Changes with Enhanced Domains Deployment.

August 28, 2024

Added the question, How can I disable legacy redirections in my production or demo org?

Updated these questions to reflect that legacy hostname redirections end in Spring '25, not Winter '25, in demo orgs.

December 8, 2024

Updated the introduction for this Knowledge Article and these questions to reflect that legacy hostname redirections end with the enforcement of the Update References to Legacy Host Names release update, which is introduced in Spring '25:

Updated these questions to use the past tense when referring to the end of redirections in Winter '25:

Added the question, Why did Salesforce delay the end of legacy redirections for production orgs?

December 13, 2024

Updated the introduction for this Knowledge Article and these questions to reflect that the Update References to Legacy Host Names release update, which is introduced in Spring '25, is enforced in Spring '26:

April 11, 2025

Added this question for the Update Instanced URLs in API Traffic release update, to be introduced in Summer '25: Do redirections stop in API traffic, too?

Updated these questions for the Update Instanced URLs in API Traffic release update, to be introduced in Summer '25.

Removed references to "future" Help updates that are now complete:

December 19, 2025

Added these questions: 

In these sections and questions, removed references to previous releases and clarified the updated timeline for the support of incorrect instanced URLs in API calls:

Other Changes:

March 26, 2026
Knowledge Article Number

000393816

 
Loading
Salesforce Help | Article