Test My Domain Changes

Test in a Sandbox

My Domain changes affect Salesforce login URLs, application URLs, and external-facing URLs such as Experience Cloud sites, Visualforce pages, and content files. To avoid end-user disruption, before you update production, it’s important that you test My Domain changes in a sandbox.

When you test in a sandbox, note the changes required to complete successful tests. Use that list to update your org when you make the same My Domain changes in production.

Note When you enable and deploy enhanced domains in a sandbox, your My Domain login URL and the URLs for your Lightning pages and Lightning container components change. These URLs don’t change when you enable and deploy enhanced domains in production unless you also change your My Domain name or suffix.

Need a refresher on sandboxes? See Sandboxes: Staging Environments for Customizing and Testing.

Update Your Org and Network Settings

When you change your My Domain details, your org’s login URL and application URLs can change. URLs that are dynamically constructed by Salesforce use the new URLs automatically, but some Salesforce functionality requires more steps. Similarly, Apex code, JavaScript code, your network configuration, and existing data that contain the old URLs aren’t automatically updated.

Ensure a smooth transition by updating references to your old URLs. For example, update your allowlists, custom Visualforce pages, the endpoint for API integration, and your identity providers with your new My Domain URLs. For more information, see Update Your Org for My Domain Changes.

Disable Redirections During Testing

When you rename your My Domain, Salesforce redirects your previous My Domain URLs to your current My Domain. To identify any issues with access to your new My Domain URLs, we recommend that you disable all redirection options during your testing.

To help your users transition to your new My Domain URLs, you can enable these redirections again after you complete your testing.

For more information, see My Domain Redirections.

Configure My Domain Policy Changes

The My Domain login policy determines whether users and SOAP APIs can use instanced URLs such as https://na139.salesforce.com to access your org in addition to the My Domain login URL.

Note This policy applies to all deployed and provisioned domains in the org.

For more information, see Set the My Domain Login Policy.

Configure My Domain Settings

My Domain settings determine the user experience when logging into your Salesforce org via your My Domain. For example, you can customize your My Domain login page and add authentication services such as single sign-on (SSO). You can update these settings after you roll your domain changes, but it’s better to set up and test them with your other My Domain changes. For more information, see Configure My Domain Settings.

Prepare for Testing

Your Salesforce org’s login and application URLs are used throughout Salesforce. For example, these URLs are used for API integrations, Experience Cloud sites, custom Visualforce pages, and custom apps. For more information, see My Domain URL Formats.

Tip The My Domain Setup page shows your org’s current My Domain login URL and the login URL for any My Domain change in progress. For the formats of the other URLs in your org, such as Visualforce pages, Salesforce Sites, and Experience Cloud sites, see My Domain URL Formats.

If you enabled enhanced domains, or if you renamed your My Domain in an org with enhanced domains enabled, the URLs for Experience Cloud sites and Salesforce Sites change. Include verification of these external-facing URLs from all access points in your test plans. For example, a site URL can be used on your website, social media pages, marketing materials, and templates such as email signatures and automated responses.

To supplement your test plans, consider including users and partners in your testing. End-user testing can help validate the most commonly used workflows. And partners can help identify and remediate access issues efficiently.

Conduct Functional, End-User, and Integration Testing

Run automated and manual tests to ensure that they pass with your updated My Domain.

Automated tests can identify issues with accessing your org. However, these tests can miss items like broken links or content on a Visualforce page. To test for these issues, log in to Salesforce, and click tabs and links. To test your external-facing links, such as Experience Cloud sites, validate access from all available points as each user type. Then work with partners to validate integrations.

In your functional, end-user, and integration tests, include these common uses for Salesforce URLs.

• The end-user login process, including multi-factor authentication.
• Your custom My Domain login page.
• Integration access to your org, such as API calls, Apex code, and external apps and systems that access your Salesforce data or provide data to your org. Also include calls made via connected apps, Lightning Out (beta), and Embedded Service Deployment (Chat).
• Computer-Telephony Integrations (CTIs), such as Salesforce Call Center, Service Cloud Voice, and Click to Dial
• External-facing sites, such as Experience Cloud sites, as authenticated and unauthenticated guest users.
• Custom domains, such as https://www.example.com, that serve your Experience Cloud sites and Salesforce Sites.
• External integrations that reference your custom domains.
• If you have IP restrictions in place and you enabled enhanced domains, test access to your Experience Cloud sites and any custom domains that serve them via IPv6.
• SSO for your Salesforce org and your Experience Cloud sites.
• SAML SSO between your orgs and Experience Cloud sites.
• If you allow users to authenticate using alternate identity provider options directly from your My Domain login page, verify that login process with each available provider. Similarly, test all browser-based authentication methods for mobile users, if available in your org.
• If you configured a Salesforce authentication provider, your users can log in to your custom external web app using their Salesforce credentials. Verify that login process with each external web app.
• If you customized your org, for example, with buttons or Visualforce pages, make sure that you test your changes thoroughly. Look for broken links due to hard-coded references. For example, look for instance-based URLs such as https://na139.salesforce.com.
  

  Tip To search your Salesforce code, download the metadata. Then use a command-line interface such as Salesforce CLI.
• Content stored in Salesforce, such as images and files. Multiple places can reference this content, including Visualforce pages, Experience Cloud sites, Salesforce Sites, and enablement sites (myTrailhead).
• Links to your Salesforce org from your sites, such as links to content, reports, files, and other sites.

Test Installed Packages

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.

Note In most cases, you can’t edit package-delivered components. If you find that you can edit a package-delivered component, don’t edit the component directly. Otherwise, the next package update can overwrite your changes.

We recommend that package developers use generated host names and relative paths to build any links. If they follow that approach, updated links work after a My Domain change, such as enabling enhanced domains. If you find an issue with components or functionality delivered by a package from AppExchange, contact the package developer. Make them aware of the issue so that they can publish a new version of their package that remediates the issue.

Test Again in Production

Before making My Domain changes in production, we highly recommend that you test those changes in a sandbox. Ideally, your sandbox includes all the functionality of production, but there can be obvious and not so obvious differences with production. For example, not all integration with third-party applications is available in sandboxes. And some data types, workflows, or complex test scenarios can only be tested in production. As a result, after you deploy a My Domain change in production, we recommend that you perform another round of testing.

Next Steps

After you complete testing, help your users get started using your new My Domain by providing links to pages that they use frequently, such as your login page. Let your users know if you changed the login policy, and encourage them to update their bookmarks the first time that they’re redirected.

If you enabled enhanced domains, update external-facing links such as publicly available Experience Cloud sites and Salesforce Sites. For example, a site URL can be used on your website, social media pages, marketing materials, and templates such as email signatures and automated responses. Create a plan to update each location, and announce the change to your users and customers.