Update Your Org for My Domain Changes

Create an inventory of links and redirections that take the user from a different Salesforce org to the org in which you plan to change the My Domain. Search across all your Salesforce orgs.

For example, a hard-coded link on a Visualforce page in a sandbox takes a user to a production URL, such as a file or another Visualforce page. Or, if you have multiple production orgs and use redirections to route users to the correct org, note the places in your code where those redirections occur.

Plan to update these links and redirections after you deploy your My Domain change.

If the redirection includes a redirection parameter in code or within a URL, also plan to update the Trusted URLs for Redirects allowlist in the org that contains the redirection. For more information, see Trust Redirections to Your Other Salesforce Orgs.

Custom Visualforce pages or custom apps

Replace references to the org’s instance URL with relative URLs and dynamically generated host names. Note any URLs that require a hard-coded reference.

For more information, see the knowledge article Updating Hard-Coded References.

To search your Salesforce code, download the metadata for each of your Salesforce orgs. 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.

Identify the web pages and sites that use your chatbots so that you can update them after you deploy the change.

For each bot, review the Permitted Domains field in the chat deployment settings. Optionally, you can update the permitted domains and update your deployment code before you deploy the My Domain change. For more information, see Create Chat Deployments.

After you deploy a My Domain change, Salesforce redirects your previous My Domain URLs. In some cases, external software calls can’t process the redirection, and the call to the Salesforce URL fails.

Before you deploy your My Domain change, verify that the external software that uses your Salesforce URLs, including site URLs, can process redirections. If the software can’t process those redirects, work with the software owner to get that redirection functionality in place or plan to update your use of the software with your new URLs after you deploy the change.

With a hard-coded URL, the URL exists in plain text in your code. Those URLs require a manual update when the URL changes. 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 URLs 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. 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 Salesforce instance and reference the My Domain URL formats.

Before you deploy your My Domain name, reduce your post-deployment effort by replacing hard-coded links with relative URLs and dynamically generated URLs. To generate My Domain URLs, use the DomainCreator Class in Apex.

Note the hard-coded URLs to update after you deploy your My Domain change.

If any authentication methods use your login URL, plan to update authentication after you deploy the My Domain change. We recommend that you document your existing settings before you deploy your My Domain change. This snapshot of your earlier configuration 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.

Identify the Visualforce pages, web pages, and other locations that call your Lightning Out app. Identify who can update the markup embedded in those pages.

Determine whether authenticated users can access Lightning Out and whether the connected app for Lightning Out uses your My Domain login URL.

• Work with your telephony provider to add your new URLs to the telephony provider’s allowlists.
• Review your configuration for any hard-coded references to your URLs. Whenever possible, update these references to relative URLs instead. For examples, see the Knowledge Article Enhanced Domains and Open CTI with Visualforce (Spring ‘23). If you find any hard-coded references that you can’t convert to a relative URL, note them and prepare to update them after you deploy your new My Domain.

When you enable Service Cloud Voice, Salesforce uses your My Domain URLs to configure single sign-on (SSO) to your telephony provider. The required action depends upon your configuration.

• If you use Service Cloud Voice with Amazon Connect or Service Cloud Voice with Partner Telephony from Amazon Connect, Salesforce updates your configuration, including the Amazon Connect allowlist, when you deploy your new My Domain. No action is required before you deploy the new My Domain.
• If you use Service Cloud Voice with Partner Telephony, work with your telephony provider to add your new URLs to their allowlist. Also identify hard-coded connect API URLs, allowlists, and references to the Next generation Omni-Channel engagement URL that ends in *.my.salesforce-scrt.com. With your telephony provider, prepare to update those hard-coded references after you deploy your new My Domain.

• Work with your telephony provider to add your new Visualforce URL to the telephony provider’s allowlists.
• Review your configuration for any hard-coded references to your Visualforce URL. Whenever possible, update these references to relative URLs instead. For examples, see the knowledge article Enhanced Domains and Open CTI with Visualforce (Spring ‘23). If you find any hard-coded references that you can’t convert to a relative URL, note them and prepare to update them after you deploy your new My Domain.

If you use Service Cloud Voice with Partner Telephony, work with your telephony provider to add your new Visualforce URL to their allowlist. Also identify hard-coded references to your Visualforce URL in your configuration. With your telephony provider, prepare to update those hard-coded references after you deploy your new My Domain.

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 when you deploy your new My Domain.

If any authentication methods use your site URL, plan to update authentication after you deploy the My Domain change. We recommend that you document your existing settings before you deploy your My Domain change. This snapshot of your earlier configuration 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.

To support redirections of your current My Domain URLs after you deploy the My Domain change, check your Mobile Publisher for Experience Cloud Apps version. If you’re running a version lower than 10.0, follow the instructions in the knowledge article Mobile Publisher for Experience Cloud Apps and Enhanced Domains, to upgrade to the latest version before you deploy your My Domain change.

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 task doesn’t apply. Also, this task doesn’t apply to Mobile Publisher for Lightning apps.

After you deploy enhanced domains, your new *.my.site.com Experience Cloud site host name supports both IPv4 and IPv6. If a profile includes IP restrictions and only IPv4 addresses are allowed, users assigned to that profile can see an error when they access your site that ends in *.my.site.com via IPv6. 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. For more information on setting IP restrictions in Salesforce, see the knowledge article Network Access, Session Settings, and Profile-based IP restrictions.

:: 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

When you deploy enhanced domains, your new system-managed Experience Cloud site *.my.site.com domain includes the Experience Cloud content delivery network (CDN), which uses the Salesforce CDN partner. The IP addresses used by the Salesforce CDN partner aren’t published. Therefore, if your network settings include IP allowlisting, users can lose access to your site that uses the Salesforce CDN. For example, if your users log in via a VPN that exclusively uses IP allowlisting, the users on that VPN can’t access your site, because it uses the Salesforce CDN partner's IP address.

To ensure that your users can access your Experience Cloud site on the Salesforce CDN, allowlist your site’s domain, or serve your site via a custom domain. For more information, see the knowledge article Access Experience Sites via an IP-Restricted VPN After Enhanced Domains Deployment.

If you can’t allowlist your domain at the network level or configure a custom domain to serve your site, plan to contact Salesforce Customer Support to disable the Salesforce CDN for your *.my.site.com site URL after you deploy enhanced domains.

If the Clickjack protection level for your site is Allow framing of site pages on external domains (Good protection), review and update the list of trusted domains. In particular, ensure that *.my.salesforce.com is trusted.

For more information, see Enable Clickjack Protection in Experience Cloud Sites and Enable Clickjack Protection in Site.com.

If you deployed enhanced domains, you can remove the domains that only apply to orgs without enhanced domains from your allowlist. However, we recommend that you keep those domains in your allowlist for redirection until all users and integrations are using your new domains successfully.

For the list of required domains and their purposes, see Allow the Required Domains.

Update references to your old My Domain URLs in your cross-org links and redirections.

If the redirection includes a redirection parameter in code or within a URL, also plan to update the Trusted URLs for Redirects allowlist in the org that contains the redirection. For more information, see Trust Redirections to Your Other Salesforce Orgs.

Custom Visualforce pages or custom apps

Replace hard-coded references to the org’s instanced URL, such as https://na170.salesforce.com, or your My Domain login URL with your new My Domain login URL.

For more information, see the knowledge article Updating Hard-Coded References.

Update these references to your current My Domain URLs. Ideally, generate the host names via a dynamic method, such as the DomainCreator Class in Apex.

If you deployed enhanced domains, review the temporary host names redirections. If you find any of those host name formats in your org, update them to the enhanced domain format.

For more information about updating hard-coded references, see the knowledge article Updating Hard-Coded References.

API integrations into your org

Check whether the API client references the server endpoint. For the API client, use the metadataServerUrl or serverURL value returned by a login request. Don’t use a hard-coded server URL.

After you deploy a My Domain change that affects your login URL, Salesforce returns the server URL containing your new My Domain name or suffix. If your org has been moved to another instance or you require SOAP API logins to use your My Domain in My Domain policies, old calls to instanced URLs fail. And API logins to a Hyperforce org can’t use an instanced URL. To avoid disruption, use the value returned by Salesforce.

Email templates

Replace references to the old URL with your new My Domain login URL. If the template uses a hard-coded URL, which is more common in email templates created in Salesforce Classic, we recommend that you update the template to use a dynamically generated URL.

Update connected apps that use your My Domain login URL.

Refresh the Lightning Out markup on Visualforce pages, web pages, and other locations that call your Lightning Out app.

If authenticated users access Lightning Out, generate a new Session ID or authentication token for those connections.

Review the URL field for your named credentials. If a named credential uses your My Domain login URL, update the URL field with your new My Domain login URL. For more information, see Update Named Credentials After a My Domain Change.

If users access functionality that relies on an updated named credential, instruct them to reauthenticate.

If your Account Engagement configuration uses the Pardot Connector User, update the login URL that Account Engagement uses. In Account Engagement, update the Pardot Connector User. To use the same user, 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.

When you deploy enhanced domains, no change to the Account Engagement tracker domain configuration is required.

• Verify with your telephony provider that your new URLs are included in the telephony provider’s allowlists. Optionally, work with the provider to remove your previous URLs from to their allowlists.
• Update any hard-coded references to your previous URLs. Whenever possible, update these references to relative URLs instead. For examples, see the knowledge article Enhanced Domains and Open CTI with Visualforce (Spring ‘23).

When you enable Service Cloud Voice, Salesforce uses your My Domain URLs to configure single sign-on (SSO) to your telephony provider. The required action depends upon your configuration.

• 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, including the Amazon Connect allowlist, when you deploy your new My Domain. Optionally, remove your old URL formats from the Amazon Connect allowlist.
• If you use Service Cloud Voice with Partner Telephony, work with your telephony provider to update your configuration with your new URLs after you deploy the new My Domain. In particular, update hard-coded connect API URLs, allowlists, and references to the Next generation Omni-Channel engagement URL that ends in *.my.salesforce-scrt.com. Optionally, work with your telephony provider to remove your previous URL formats from their allowlist.

To ensure continuity during instance refreshes and org migrations, we recommend using My Domain URLs with Streaming API. If you follow this recommendation, replace your previous My Domain login URL with your new login URL.

If you don’t follow this recommendation yet, use your My Domain login URL with Streaming API. For example, replace https://login.salesforce.com and https://InstanceName.salesforce.com​/ with https://MyDomainName.my.salesforce.com​/.

For more information on logging in to Salesforce with your My Domain URL, see Log In to Salesforce with Code.

• Verify that your new Visualforce URL is included in the telephony provider’s allowlists. Optionally, work with the provider to remove your previous Visualforce URL from to their allowlists.
• Update any hard-coded references to your previous Visualforce URL. Whenever possible, update these references to relative URLs instead. For examples, see the knowledge article Enhanced Domains and Open CTI with Visualforce (Spring ‘23).

If you use Service Cloud Voice with Partner Telephony, work with your telephony provider to update your configuration, including allowlists, with your new Visualforce URL. Optionally, work with your telephony provider to remove your previous Visualforce URL from their allowlist.

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 when you deploy your new My Domain. Optionally, you can update your Amazon Connect allowlist to remove your old Visualforce URL format.

Update any hard-coded links to Experience Cloud sites and Salesforce Sites in your sites and custom pages. For example, if you host knowledge articles on an Experience Cloud site, update the URLs that include your old site URL. These links are redirected to the equivalent current site URL until you disable those redirections or until Salesforce stops those redirections. See Prepare for the End of Redirections for Non-Enhanced Domains.

When you update these hard-coded links, use relative paths and dynamically generated host names whenever you can. If your site URL changes again in the future, relative paths and dynamically generated host names continue to work.

Update connected apps that use your Experience Cloud URL.

If authenticated users access Lightning Out, generate a new Session ID or authentication token for those connections.

Update your app to use your new Experience Cloud sites URL before Salesforce stops redirections for your old site URL. For more information, see Prepare for the End of Redirections for Non-Enhanced Domains and Mobile Publisher for Experience Cloud.

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 task doesn’t apply. Also, this task doesn’t apply to Mobile Publisher for Lightning apps.

When you deploy enhanced domains, your new system-managed Experience Cloud site *.my.site.com domain includes the Experience Cloud content delivery network (CDN), which uses the Salesforce CDN partner. The IP addresses used by the Salesforce CDN partner aren’t published. Therefore, if your network settings include IP allowlisting, users can lose access to your site that uses the Salesforce CDN. For example, if your users log in via a VPN that exclusively uses IP allowlisting, the users on that VPN can’t access your site, because it uses the Salesforce CDN partner's IP address.

To ensure that your users can access your Experience Cloud site on the Salesforce CDN, allowlist your site’s domain, or serve your site via a custom domain. For more information, see the knowledge article Access Experience Sites via an IP-Restricted VPN After Enhanced Domains Deployment.

If you can’t allowlist your domain at the network level or configure a custom domain to serve your site, contact Salesforce Customer Support to disable the Salesforce CDN for your *.my.site.com site URL.