--- schema_version: "1" id: c49ebb3ca2fca4842e985e273aa0279fd13f897df22a4e967da7618711eafe8f title: Review Recommended Practices for a My Domain Change collection: admin version: current locale: en-us portal_url: https://docs.salesforce.com/admin/current/en-us/xcloud/264-0-0/domain_name_plan_recommendations.md canonical_url: https://help.salesforce.com/s/articleView?id=xcloud.domain_name_plan_recommendations.htm&release=264.0.0&type=5 source_site: help.salesforce.com content_type: documentation content_hash: 72333dd5c1e3851f8015de61296a076648e57ce1ae95ef1b22e107917cd3605d description: Before you deploy a change to your My Domain, consider configuring a custom domain to serve your sites, and review your My Domain settings. Review recommendations for testing and go-live plans. Understand the steps that you can make only after you deploy a My Domain change, and follow recommendations to minimize disruption during your deployment. After you complete testing, notify users, enable redirection logging, and determine when to disable redirections. products: - Salesforce Platform - Cross Cloud release: "264" --- # Review Recommended Practices for a My Domain Change Before you deploy a change to your My Domain, consider configuring a custom domain to serve your sites, and review your My Domain settings. Review recommendations for testing and go-live plans. Understand the steps that you can make only after you deploy a My Domain change, and follow recommendations to minimize disruption during your deployment. After you complete testing, notify users, enable redirection logging, and determine when to disable redirections. ### Required Editions
Available in: both Salesforce Classic and Lightning Experience
Available in: Group, Essentials, Professional, Enterprise, Performance, Unlimited, and Developer Editions
![Note](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-xcloud-setup-264-0-0-production-enus/6f21df35-9ea0-4f53-ac94-45c3b5dfd5bc/images/icon_note.png) Note Enhanced domains were enforced in Winter ’24. For more information, see [Enhanced Domains Timeline](https://help.salesforce.com/s/articleView?id=xcloud.domain_name_enhanced_timeline.htm&release=264.0.0&type=5 "To prevent disruption for your customers and users, review the enhanced domains timeline and prepare for upcoming changes. Redirections for legacy host names stopped in production and demo orgs in Spring ’26. And in Winter ’27, Salesforce ends support for API traffic that uses an incorrect instanced URL."). To assist customers who continue to test after deploying enhanced domains, these checklists include steps that are specific to that 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](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-xcloud-setup-264-0-0-production-enus/6f21df35-9ea0-4f53-ac94-45c3b5dfd5bc/images/icon_important.png) 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](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-xcloud-setup-264-0-0-production-enus/6f21df35-9ea0-4f53-ac94-45c3b5dfd5bc/images/icon_note.png) 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](https://help.salesforce.com/s/articleView?id=xcloud.domain_name_redirections.htm&release=264.0.0&type=5 "When you deploy a change to your My Domain, Salesforce redirects multiple host names automatically. Learn about the types of redirections, how to log redirections for the host names that Salesforce hosts for your org, and how you can control these 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](https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_intro.htm). 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](https://help.salesforce.com/s/articleView?id=xcloud.domain_name_app_url_changes.htm&release=264.0.0&type=5 "Your My Domain name is a subdomain used in login URL and application URLs across your Salesforce org, including sites and Visualforce pages. Understand what determines your org’s URL formats and the structure of those 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](https://help.salesforce.com/s/articleView?id=xcloud.domain_name_guidelines.htm&release=264.0.0&type=5 "When you deploy a change your My Domain, your Salesforce org’s login URL and application URLs change. URLs that are dynamically constructed—for example, URLs generated via the DomainCreator Apex class—use the new URLs automatically. However, some Salesforce functionality requires an update to work with your new URLs. Similarly, custom code, your network configuration, and third-party integrations that use the old URLs require updates. To ensure a smooth transition to your new URLs, update references to your old URLs."). - 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](https://help.salesforce.com/s/articleView?language=en_US&type=1&id=Potential-Service-Disruptions-with-Enable-Enhanced-Domains-for-Mobile-Publisher-for-Experience-Cloud-Apps) 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](https://help.salesforce.com/s/articleView?id=xcloud.domain_name_settings.htm&release=264.0.0&type=5 "Customize your login page with your brand and determine the user experience when they log into your Salesforce org via your My Domain.") and [My Domain Redirections](https://help.salesforce.com/s/articleView?id=xcloud.domain_name_redirections.htm&release=264.0.0&type=5 "When you deploy a change to your My Domain, Salesforce redirects multiple host names automatically. Learn about the types of redirections, how to log redirections for the host names that Salesforce hosts for your org, and how you can control these 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](https://help.salesforce.com/s/articleView?id=xcloud.domain_name_auth_update_determine.htm&release=264.0.0&type=5 "If your My Domain login URL or site URL changes, authentication updates are required. Determine whether these changes apply to your My Domain change. Then understand the types of updates required."). - 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](https://help.salesforce.com/s/articleView?id=xcloud.domain_name_login_code.htm&release=264.0.0&type=5 "For an extra layer of security, use your My Domain login URL to access your Salesforce org with code. Compare the benefits of your My Domain login URL versus the default Salesforce login URL. And understand why we recommend that you update the login URLs that contain your Salesforce instance.") and [DomainCreator Class](https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_class_System_DomainCreator.htm) 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](https://help.salesforce.com/s/articleView?id=platform.domain_mgmt.htm&type=5&language=en_US). - 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](https://help.salesforce.com/s/articleView?id=sales.emailadmin_async_email_verification.htm&type=5&language=en_US). ## 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](https://help.salesforce.com/s/articleView?id=xcloud.domain_name_guidelines.htm&release=264.0.0&type=5 "When you deploy a change your My Domain, your Salesforce org’s login URL and application URLs change. URLs that are dynamically constructed—for example, URLs generated via the DomainCreator Apex class—use the new URLs automatically. However, some Salesforce functionality requires an update to work with your new URLs. Similarly, custom code, your network configuration, and third-party integrations that use the old URLs require updates. To ensure a smooth transition to your new URLs, update references to your old URLs.") and the [example checklists](https://help.salesforce.com/s/articleView?id=xcloud.domain_name_plan_checklists.htm&release=264.0.0&type=5 "Review example checklists for a My Domain change, including a project checklist, pre-deployment checklist, and post-deployment checklist.") 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](https://appexchange.salesforce.com/), 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](https://help.salesforce.com/s/articleView?id=xcloud.domain_name_plan_checklist_project.htm&release=264.0.0&type=5 "The items on this list help with planning, scheduling, and performing a My Domain change."). For example steps to perform after you deploy your My Domain change, see the example checklists for [pre-deployment](https://help.salesforce.com/s/articleView?id=xcloud.domain_name_plan_checklist_pre.htm&release=264.0.0&type=5 "The items on this checklist don’t require the new My Domain URLs to be accessible.") and [post-deployment](https://help.salesforce.com/s/articleView?id=xcloud.domain_name_plan_checklist_post.htm&release=264.0.0&type=5 "The items on this checklist require your new My Domain URLs, so you can only complete them after you deploy the new My Domain.") 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](https://help.salesforce.com/s/articleView?id=xcloud.domain_name_redirections_manage.htm&release=264.0.0&type=5 "Control whether to redirect users who visit your previous My Domain URLs to the current My Domain URL. To help your users adopt the new URLs after a My Domain change, optionally turn on a brief message during My Domain URL redirections. And test the end of support for incorrect instanced URLs in API traffic."). 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](https://help.salesforce.com/s/articleView?id=xcloud.domain_name_redirections_non_enhanced.htm&release=264.0.0&type=5 "After enhanced domains deployment, your previous non-enhanced host names were redirected. In Winter ’25, Salesforce stopped redirections for legacy (non-enhanced) My Domain URLs in Developer Edition orgs, patch orgs, scratch orgs, Trailhead Playgrounds, and existing sandboxes. Redirections for those legacy URLs stopped in Spring ’26 in all orgs, including production orgs. If your org was created before October 2020, Salesforce also stopped redirections for host names that contained your instance name but not your My Domain. And in Winter ’27, support ends for incorrect instanced URLs in API calls. Review the affected host names and how to test for the end of these redirections."). 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](https://help.salesforce.com/s/articleView?id=xcloud.domain_name_redirections_log.htm&release=264.0.0&type=5 "To reduce disruption, Salesforce redirects multiple host names automatically when you deploy a change to your My Domain. To track blocked and successful redirections for your My Domain host names, enable event logging for these redirections.") and the [Hostname Redirects Event Type](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_eventlogfile_hostnameredirects.htm) 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](https://help.salesforce.com/s/articleView?id=xcloud.domain_name_redirections.htm&release=264.0.0&type=5 "When you deploy a change to your My Domain, Salesforce redirects multiple host names automatically. Learn about the types of redirections, how to log redirections for the host names that Salesforce hosts for your org, and how you can control these redirections."). If you choose to remove redirections for your previous host names, treat it as a second My Domain change for testing and communications. #### See Also - [My Domain](https://help.salesforce.com/s/articleView?id=xcloud.domain_name_overview.htm&release=264.0.0&type=5 "Showcase your company’s brand with a customer-specific subdomain name in your Salesforce org URLs. With My Domain, you can include your company name in your URLs, for example, https://mycompany.my.salesforce.com. With these org-specific URLs, you can set up a custom login page, set a custom login policy, offer single sign-on, and allow users to log in with a social account. My Domain also allows you to work in multiple Salesforce orgs in the same browser at the same time.") - [Plan for a My Domain Change](https://help.salesforce.com/s/articleView?id=xcloud.domain_name_plan.htm&release=264.0.0&type=5 "Whether you change your My Domain to update your brand, to adopt enhanced domains, or to enable partitioned domains, the URLs that Salesforce hosts for your org change. Those changes can have a large impact, and making the required updates can seem like a daunting project. To make the process as smooth as possible for you, your users, and your customers, review the high-level steps, the recommended practices, and how to reduce the impact on your users and customers.")