Review Recommended Practices for a My Domain Change

Recommended Steps Before a My Domain Change

• Preserve Access—When your My Domain login URL or site URL changes, authentication methods such as single sign-on (SSO) and multi-factor authentication (MFA) can stop working. Before you deploy a change to your My Domain, preserve login access for your admins and users.
  

  Important If you don’t follow this guidance before you deploy a change to your My Domain login URL, you can be locked out of your Salesforce org.
• Confirm that Your My Domain Name Reflects Your Brand—With enhanced domains, all the URLs that Salesforce hosts for your org include your My Domain name, including the system-managed Experience Cloud sites and Salesforce Sites URLs. If your change includes deploying enhanced domains, verify that your My Domain name reflects your external brand. If not, you can rename your My Domain as part of your My Domain change.
  

  Note If you use a custom domain such as https://www.example.com, your system-managed site URLs aren’t visible to your customers.
• Provision Early—To deploy your changes on your schedule, save your desired My Domain change at least 1 day before your scheduled deployment.

  After you save a change to your My Domain, Salesforce then provisions the domains. In other words, we get the new My Domain URLs ready for activation. The provisioning process usually finishes in a few minutes, but it can take up to 24 hours. Issues with provisioning are rare, but sometimes they require that you stop the process and save your My Domain change again, which restarts the process.

  When the provisioning process is complete, the admin who requested the change receives an email. You can leave your new My Domain in a provisioned status as long as you need. Or, if you choose not to deploy the new Domain, you can cancel the change.

  Most importantly, until you deploy your My Domain, user connections are unaffected. If a user visits the new My Domain login URL, they’re redirected to the original My Domain login URL. Otherwise, no one can access the new domains.

• Understand Redirections After a My Domain Change and Disable Redirections During Testing—Each time that you deploy a change to your My Domain details, Salesforce redirects your previous My Domain host names to the host names for your current My Domain unless you disable those redirects. However, if you change your My Domain more than one time, only the last set of My Domain URLs for your org are redirected. Before you deploy a My Domain change, consider the impact on any existing My Domain URL redirections. To see if redirects are in place for a previous My Domain, check the Redirections section of the My Domain page.

  My Domain URL redirections help prevent disruption, but they’re not intended as a permanent solution. Not all services work well with redirections, and a redirection adds a step to the process of loading the final web page. When you deploy a new My Domain, we highly recommend that you disable redirections during testing and update all references to your old URLs.

  For more information on redirections, the settings that control them, and how to log My Domain host name redirections, see My Domain Redirections.

• Create an inventory of your hard-coded Salesforce org URLs—With a hard-coded URL, the URL exists in plain text in your code. Those URLs require a manual update when the URL changes, such as with a My Domain change or an org migration. For this reason, Salesforce recommends that you use relative and dynamically created URLs instead of hard-coded URLs whenever possible.

  The first step to addressing hard-coded links is to find where they exist in your Salesforce orgs. An inventory can help you complete the required updates to your org and include the relevant functionality in your testing.

  To search your Salesforce code, download the metadata for each of your Salesforce orgs via a tool such as Salesforce CLI. Then use a code editor such as Microsoft Visual Studio to search for URLs that belong to the org in which you plan to change the My Domain. To determine what to search for, you can use your instanced URL and reference the My Domain URL formats.

  Because of the time it can require, we recommend that you create the inventory early in the My Domain change process. We also recommend that your inventory identifies the URLs that point to a different Salesforce org.

• Computer-Telephony Integrations (CTIs), such as Open CTI and Service Cloud Voice: Engage with Telephony Providers—When you deploy enhanced domains or deploy a My Domain name change, the URLs used in your Open CTI or Service Cloud Voice configuration change.

  If you use Open CTI for integrations such as Salesforce Call Center and Click to Dial, work with your telephony provider to add your new URLs to the telephony provider’s allowlists. Also review your configuration for any hard-coded references to your Salesforce URLs. Whenever possible, update those hard-coded references to relative URLs instead.

  If you use Service Cloud Voice with Amazon Connect or Service Cloud Voice with Partner Telephony from Amazon Connect, no action is required. Salesforce updates your configuration for you when you deploy your new My Domain.

  If you use Service Cloud Voice with Partner Telephony, connect with your telephony provider. Add your new URLs to their allowlist and coordinate with your provider to update your configuration with your new URLs after you deploy the change.

  For more information, see Update Your Org for My Domain Changes.

• Upgrade Mobile Publisher for Experience Cloud Apps—If you configured a Mobile Publisher for Experience Cloud app that uses your .force.com Experience Cloud site URL, before you enable and deploy enhanced domains in production, upgrade to Mobile Publisher version 10.0 or later. For instructions, see Mobile Publisher for Experience Cloud Apps and Enhanced Domains

  If you use a custom domain such as https://www.example.com to host your Experience Cloud site and use that custom domain for your Mobile Publisher app, this restriction doesn’t apply. Also, this restriction doesn’t apply to Mobile Publisher for Lightning apps.

• Review Your My Domain Configuration—A My Domain change is a great time to review your existing configuration, record it for testing and post-deployment verification, and make any changes. For example, on your My Domain login page, update the branding or add the option to log in via an identity provider. To review the available configuration options, see Configure My Domain Settings and My Domain Redirections.
• Document Your Current Authentication Configuration—If your My Domain change updates your My Domain login URL, Experience Cloud sites URL, or Salesforce Sites URL, we recommend that you document your existing settings before you deploy your My Domain change. This snapshot is a valuable reference for your rollback plan. For more information about the settings to capture, see Determine the Required Authentication Updates After a My Domain Change.
• Replace Login References with Dynamically Created Host Names—For stability and an extra layer of security, we recommend that you use your My Domain login URL to log in to Salesforce with code. To insulate these references against future My Domain changes, use Apex to retrieve the URL. To get the host name of your My Domain login URL in Apex, use the getOrgMyDomainHostname() method of the System.DomainCreator class. If you use the system-managed host name to log in to your Experience Cloud site, use the getExperienceCloudSitesHostname() method of the System.DomainCreator class to get that host name.

  You can use dynamically created host names before you deploy your My Domain change. With dynamically created host names, any change to the corresponding system-managed URL doesn’t affect the related code. This approach reduces your post-deployment effort.

  For more information, see Log In to Salesforce with Code and DomainCreator Class in the Apex Developer Guide.

• Consider a Custom Domain to Serve Your Sites—Custom domains allow you to use a domain that you own, such as https://www.example.com, to serve your Experience Cloud sites and Salesforce Sites. Although your Salesforce org provides the content, the site is served on your custom domain, providing a clear branded experience for your users. For this reason, Salesforce recommends that you serve your sites on a custom domain.

  If you’re considering a custom domain, we recommend that you set up the custom domain before any pending My Domain changes, if possible. Even if the system-managed site URL changes, your customers continue to use the custom domain. That stability reduces the number of updates required after a My Domain change. For example, if you reference your site URL in marketing materials, emails, social media pages, and templates, the custom domain remains valid.

  For more information, see Custom Domains.

• Consider Verifying User Addresses—A change to your My Domain login URL is a great time to verify your users as part of rolling out the new login URL. Use async email verification to send email messages to internal and external users to ensure that they’re registered with a valid email address that they own. Async email messages contain a verification link (URL). You can also brand the verification email messages by customizing the email template.

  For more information, see in Verify Email Addresses with Async Email.

Understand When to Make Updates to Your Org

To create your test and go-live plan, review how to update your org for a My Domain change and the example checklists for a My Domain change.

Not all steps apply to every org. When you create your plan, remove the inapplicable steps for your My Domain change. Then prioritize the updates to make after you deploy your My Domain change. For example, authentication and allowlists are essential to complete before the bulk of users start testing.

To reduce downtime in production, identify which updates you can make before you deploy your My Domain change. Then make as many of those updates as possible in production before you deploy the change.

To help you estimate the amount of time needed for production deployment, note the updates that require the new My Domain URLs, and include the updates in your go-live plan.

Test Plan Recommendations

Regardless of whether you have a small or large team for testing, a test plan helps ensure that you cover the required areas of testing.

Here are some recommendations for a My Domain change test plan.

• Test My Domain changes in a sandbox before you update production. You can’t test in production without impacting users. After you deploy a My Domain change, it immediately applies to all users and third parties that access your org.
• Prioritize the areas to test. If you have automated tests, run those tests before you start end-user testing. Focus on the biggest impact to your business and the areas for which issue resolution can take the longest. For example, some customers test public-facing sites and revenue-generating functionality first. Or to provide more time for troubleshooting while your testers are engaged, you can prioritize complex customizations. And because resolving issues with package-delivered functionality often requires working with the package developer, test important package features early.
• If you installed packages from AppExchange, include the package-delivered functionality and components in your testing. Focus on components with links. For example, a package-delivered Visualforce page can contain links to your sites, content, or other Visualforce pages. To help triage any issues, we recommend that you note your installed packages and the corresponding functionality in your test plan.

  In most cases, you can’t edit those package-delivered components. And if you can update one of those components, a future package update can overwrite your changes.

  We recommend that AppExchange package developers use relative paths to build any links. If they follow that approach, updated links work after a My Domain change, such as enabling enhanced domains. However, not all package developers follow that recommendation. If you find an issue with components or functionality delivered by a package, remediation can require an updated version of the package. For that reason, we recommend that you test package-delivered functionality early in your testing and that you build time into your overall project for package remediation.

• Whenever possible, provide testers with clear instructions on how to test each feature. If your testers are experienced users who are familiar with all the functionality, it can be unnecessary to spell out each step but it’s always helpful to include the expected results.
• Determine the differences in testing in your sandbox versus go-live testing in production. We recommend testing thoroughly in your sandbox. However, due to the assumption that major issues were discovered during sandbox testing, production testing is often less detailed. Decide whether your approach to testing requires two versions of your test plan.

Go-Live Plan Recommendations

A go-live plan ensures that you complete the essential steps when you deploy the change in production.

Here are some recommendations for a My Domain change go-live plan.

• Include steps for provisioning the change and verifying that the change is ready to be deployed.
• Many of these changes, such as updating allowlists and hard-coded URLs, can be made in production before you deploy your new My Domain. To reduce downtime in production, make as many of these changes before your go live as possible.
• Detail any steps that you can only perform after the My Domain change is deployed. Make all other changes before the production deployment window.
• Clarify owners and the proposed timing for each step with all participants.
• Schedule a maintenance event for any impacted public-facing sites.
• As part of the final go-live preparation, confirm the availability and contact details for all participants.
• Include relevant notifications for users and customers in your plan.
• To minimize the impact on your users and customers, deploy your new My Domain when your org receives minimal traffic, such as during the weekend.
• Put mechanisms in place to make public-facing sites available as soon as the related testing is complete.

For an example of the high-level steps, see the Prepare to Update Production, Update Production, and Post-Deployment Adoption sections of the example My Domain Change project checklist. For example steps to perform after you deploy your My Domain change, see the example checklists for pre-deployment and post-deployment task example checklists.

Post-Deployment Recommendations

After you deploy a My Domain change, Salesforce redirects your previous host names. To help your users update their outdated bookmarks and links, let them know about the new URL before they’re redirected. Enable the My Domain option Notify users before redirecting to the current My Domain URL. See Manage My Domain Redirections.

If you enabled and deployed enhanced domains, Salesforce stopped some of those redirections in Winter ’25 for sandboxes, Developer Edition orgs, patch orgs, scratch orgs, and Trailhead Playgrounds. In production orgs and demo orgs, those redirections stop in Spring ’26. Review the affected host names and test for the potential impact of that change. For more information, see Prepare for the End of Redirections for Non-Enhanced Domains.

To detect visits of your old host names, we recommend that you enable host name redirection logging. Then, to collect host name redirection logs for multiple days, schedule a daily query of the Hostname Redirects event type via REST API. For example, you can configure a cron job in Unix or a scheduled task in Windows to run the query. For more information, see Log My Domain Host Name Redirections and the Hostname Redirects Event Type in Object Reference for the Salesforce Platform.

Consider whether to disable all previous redirections. For example, if your brand changed, determine whether you want users to be able to access your Salesforce org or sites via references to your previous My Domain. For more information on redirections, see My Domain Redirections. If you choose to remove redirections for your previous host names, treat it as a second My Domain change for testing and communications.