Prepare for and Schedule a My Domain Change
To prepare for a My Domain change, first gather the key information: the required updates, testing, and participants. Then review the deployment process for a My Domain change, identify your testing environment, and schedule your testing and production deployment.
Required Editions
| Available in: both Salesforce Classic and Lightning Experience |
| Available in: Group, Essentials, Professional, Enterprise, Performance, Unlimited, and Developer Editions |
Determine the Scope
| Task | Details |
|---|---|
| Learn about enhanced domains | If your My Domain change includes enhanced domains, review Enhanced Domains and the considerations for
enhanced domains. You can also watch the To get the latest updates and ask questions about this feature, join the My Domain and Enhanced Domains Trailblazer Community group. |
| Review the My Domain provisioning and deployment process | When you save a change to your My Domain name, Salesforce provisions the new URLs before you can deploy them to your users. To learn about how each step of the process impacts your users’ access to Salesforce and why it’s important to test these changes in a sandbox, review the process. |
| Determine the host names that change | Review the My Domain URL formats and determine which of those host names your My Domain change updates. If your project involves renaming your My Domain, all the host names in those lists change. If you plan to enable and deploy enhanced domains, review the changes specific to that deployment. And if you plan to enable partitioned domains in a non-production org, review the list of host names that contain the partition name after the change. |
| Note whether your login URLs change | 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 note the authentication updates required and any third parties involved with those updates. For details, see Determine the Required Authentication Updates After a My Domain Change. |
| Create an inventory of hard-coded Salesforce org URLs | If your URLs change, some steps are required before and after you deploy your My Domain change. Search all your Salesforce orgs for hard-coded URLs that point to the Salesforce org where you’re making the My Domain change. Create an inventory so that you can address these URLs before or after you deploy your My Domain change. 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 for the org in which you plan to change the My Domain. |
| Identify the features that require an update | For a list of items to update before and after your My Domain change, see Update Your Org for My Domain Changes. However, you probably don’t use every feature on the list. Identify the updates to make as part of your testing and deployment process. Optionally, you can use the example pre-deployment and post deployment task checklists to track the items to update and test. |
| Review recommended practices and identify any additional changes | Salesforce recommends several steps before and after you deploy a My Domain. Determine which recommendations to adopt, and include any relevant steps in your testing and go-live plans. Also factor those steps into your project timelines. For example, if you decide to set up a custom domain to serve your sites, include the time required for that project in your overall project timeline. |
Determine Your Project Participants
| Task | Details |
|---|---|
| Identify participants for the required updates | Now that you know which of your features are impacted, determine who can make the required changes. For example, if your My Domain change requires an update to your domain allowlists, identify who can make that update. Review your integrations and external applications, then determine the involvement and support required from each third party. For example, if your My Domain change requires updating authentication settings, connect with your identity provider (IdP). |
| Identify testers | Use the list of impacted features and your test plan to identify testers. If possible, include knowledgeable end users in your testing, especially for key features. Many tasks in Salesforce can be performed in multiple ways. These users can uncover issues that automated tests can miss. |
| Identify communication owners | Using your communication plan, identify the owners for each communication in your project participant list. |
| Identify go-live participants | Use your go-live plan to determine participants for that event. In addition to people assigned specific tasks, identify anyone required to resolve potential issues discovered during testing. For example, if your custom domain serves your Experience Cloud site, arrange for coverage with the DNS provider and any external hosting providers. |
| Collect contact information | Collect contact information for all project participants. For anyone involved in updating production, collect phone numbers and backup contacts. If you plan to publish a contact sheet for the go-live in production, verify whether the go-live participants are comfortable sharing their contact information with the group. |
Develop Testing, Communication, and Go-Live Plans
| Task | Details |
|---|---|
| Identify any features that automated tests cover | Review any automated tests that you plan to run as part of your verification. Identify features that are impacted by the My Domain change that are covered by these tests. This information can help you prioritize your testing. |
| Create a test plan | 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. For more recommendations on test plans, see Review Recommended Practices for a My Domain Change. |
| Determine how to capture testing results | Provide a standard method for reporting issues discovered during testing. As you resolve issues, note the changes that are made in the sandbox. You can use that list to update production. Some items that you uncover can only be performed after the change is deployed and your new My Domain URLs are available. Include these items in a checklist for the tasks to perform after you deploy in production. |
| Develop a communication plan | A My Domain change can impact users who log in to your Salesforce org and external users, such as visitors to your Experience Cloud sites. As part of your planning, develop a communication plan, and identify the owners for each communication. For more information on recommended communications, see Notify Users and Customers About a My Domain Change. After you identify the owners, confirm the lead time required for each communication method. As part of your plan, specify the conditions required before each communication is sent and methods for the owners to get updates on the status of the project. |
| Create a go-live plan | A go-live plan ensures that you complete the essential steps when you deploy the change in production. For more recommendations on a go-live plan, see Review Recommended Practices for a My Domain Change. |
| Develop a rollback plan | The best deployment plans include contingency planning. If you discover a high-impact issue that can’t be resolved quickly during your go live, you can restore your original My Domain state. Define a plan for rolling back to the previous state. To roll back a deployed My Domain change, typically you provision and deploy a change with your previous My Domain details. In the rollback plan, include reversing the changes made after you deployed the My Domain change and testing again. Because reversing a deployed My Domain change involves deploying another My Domain change, it can impact existing redirections. For more information, see My Domain Redirections. |
Schedule Your My Domain Change
| Task | Details |
|---|---|
| Identify or create a sandbox for testing | Decide the sandbox or sandboxes to use when you test the My Domain change. Confirm when the sandboxes are available, and identify any steps and lead time required to grant access to your testers. For more information on sandboxes, see Sandboxes: Staging Environments for Customizing and Testing in Salesforce Help and the Set Up a Sandbox in Your Salesforce Org unit in Trailhead. You can’t test enabling partitioned domains in a sandbox. If you have multiple orgs of the same non-production type, you can test partitioned domains before enabling them in other orgs of the same type. For example, you can enable partitioned domains in a Developer Edition org that you use less often before you enable the feature in your primary Developer Edition org. |
| Determine your target project dates and dependencies | To determine your target dates, discuss the project with stakeholders. If your My Domain change requires the completion of another project, work closely with the owner of that project to align the dates. If other projects require the new My Domain URLs, discuss their targeted completion date, then align the project dates and expectations. If your My Domain change includes enabling and deploying enhanced domains, that feature is enforced in Winter ’24. To verify when enhanced domains are deployed or required in your org, you can find that information on the My Domain Setup page. To find the specific date that you get a release, go to Trust Status, search for your My Domain name, and select your Salesforce instance. Then select the Maintenance tab. For more information, see Get Your Org Status and Upcoming Maintenance Dates with My Domain. |
| Choose your testing and deployment windows | Identify any other projects planned or in flight during your planned project timeline, which Salesforce sandboxes those projects plan to use, and any overlapping feature changes. Given that project information, plus your project scope and participants, coordinate with your participants to determine the timeline for deploying the My Domain change in a sandbox, testing, and capturing test results. Estimate the amount of time required to resolve any issues that arise, and then schedule a target deployment window for production. To minimize the impact on your users and customers, we recommend that you deploy your new My Domain when your org receives minimal traffic, such as during the weekend. |
| Finalize and share your schedule | After collecting input from all participants, share and confirm the timeline and the primary points of contact for participants and stakeholders. |
