Updating Hard-Coded References

General FAQs
1. What are hard-coded references (i.e. instance-specific references)

A hard-coded reference is a URL or host name that contains your Salesforce instance name.  For example,  na1.salesforce.com.  Replace these hard-coded references with URLs with a relative URL, with your My Domain login host name, or with a dynamically-generated host names.

Here's an example of a hard-coded reference: https://na1.salesforce.com/{Case.Id}
To make this a relative-reference, remove 'na1.salesforce.com' so that it becomes: /{Case.Id}

Hard-coded references can also exist in code, API calls, and feature configurations. In that case, we recommend that you use your My Domain login URL or a dynamically-generated host name.

For example, instead of https://na1.salesforce.com/services/Soap/c/65.0, use https://{myDomainName}.my.salesforce.com/services/Soap/c/65.0. For more information, see Log In to Salesforce with Code.

NOTES: 

• If your org is on Hyperforce, your instanced URL looks different. For example, swe54.sfdc-cehfhs.salesforce.com. And you can’t use that URL in calls like the examples above.

• Within Salesforce, relative references automatically direct you to the correct record. External requests should be sent to a generic endpoint, such as: <myDomainName>.my.salesforce.com, instead of https://na1.salesforce.com.

2. How can I find hard-coded references?

Search for hard-coded references with Salesforce Extensions for Visual Studio Code
The Salesforce Extensions for Visual Studio Code is a developer tool that can be leveraged to find hard-coded references. Follow the steps in the article, Creating a Salesforce Project in Visual Studio Code and Searching for Hard-Coded References, to update hard-coded references* in your org and your org's metadata (setup or customer code).

3. How do I update hard-coded references in integrations?

For your integrations to Salesforce products or sites, use the corresponding My Domain host name. For example:

• To log in to your Salesforce org: https://{myDomainName}.my.salesforce.com/services/Soap/u/65.0
• To log in via your Digital Experiences site: https://{myDomainName}.my.site.com/services/Soap/u/65.0
• To log in via your Salesforce Site: https://{myDomainName}.my.salesforce-sites.com/path-prefix/services/Soap/u/65.0

The login() call will establish a session and respond with the login server URL. Set this server URL as the target server for subsequent API requests, and set the returned session ID in the SOAP header to provide server authorization for subsequent API requests.

Instance Refresh & Org Migration-Related FAQs
These hard-coded references questions may be relevant when you are preparing to move to a new instance.

4. What hard-coded references can Salesforce servers redirect after moving to a new instance?

Because some hard-coded references aren’t redirected after an instance refresh or org migration, we highly recommend that you remove all hard-coded references before a move.

The following is a list of items that Salesforce servers canredirect, however you may experience slow performance when using these objects after moving to a new instance: 

i. Browser links
ii. Browser bookmarked URLS
iii. Custom buttons
iv. Content URLs
v. Chatter posts
vi. Self-Service Login URLs (sserv/login.jsp?orgid)
vii. Integrations

Note: Hard-coded references for sandbox instances are no longer redirected after moving to a new instance.
For non-sandbox production instances, redirections of hard-coded references continue to work until the Spring ’26 release except for InstanceName.salesforce.com / InstanceName-api.salesforce.com, which no longer redirects after moving to a new instance.

5. What hard-coded references must be updated (i.e. won't redirect) prior to moving to a new instance?

In Spring ’26, starting in January 2026, redirections stop for My Domain host names that contain an instance name and API traffic that uses an incorrect instanced host name is no longer redirected.

Make sure that you update all references, with special attention paid to:

• API calls and integrations
• Apex Web Services Generated WSDLs
• CTI integrations
• Custom Domains that are served by a third party. For example, a third-party host, CDN, or WAF.
• Custom email thread IDs
• Custom Apps
• Custom Visualforce pages
• Images in knowledge Articles and email templates. Ensure those images have been uploaded from your computer as opposed to a web address.
• Partner portals
• Remote site names
• Salesforce Chat (formerly known as Live Agent or SOS)
• Salesforce Mobile SDK
• Web-to-Leads/Cases (W2X)

Replace references to the org’s instanced URL with relative URLs and dynamically-generated host names. For images, download and re-upload the images directly from your computer.

Related Articles:

• Salesforce Help: Enhanced Domains Timeline
• Salesforce Help: Prepare for the End of Redirections for Non-Enhanced Domains
• Winter ’26 Release Note: Update Instanced URLs in API Traffic (Release Update)
• Winter ’26 Release Note: Update References to Legacy Host Names (Release Update)

6. How can I verify that all images within my Knowledge articles and email templates have been uploaded from my computer as opposed to web address?

If an image has been uploaded from a local machine, the image URL should read “https://[HOST-OR-MY-DOMAIN]/servlet/rtaImage…”.

If an image has been linked from a web address (or your Documents tab), the image URL should read “https://[HOST-OR-MY-DOMAIN]/servlet/servlet.ImageServer...” or “https://[HOST-OR-MY-DOMAIN]/servlet/servlet.FileDownload…”

7. How do I update images in my knowledge articles and email templates that use a web address?

Download the image to your computer. Then re-upload the image. Select the "Upload Image" option when you insert the image in a knowledge article or email template. 

NOTE: If images are broken after the maintenance because they use a web address: 

1. To access the image, replace the old instance name in the image URL with your new instance name. 
2. Download the image to your computer
3. Re-upload the image from your computer.
4. Verify that the image displays as expected.
   

8. Do I need to make any changes to my custom domain if I’m moving to Hyperforce or to a new instance?

A custom domain serves your Digital Experiences or Salesforce Sites on a domain that you own, such as https://www.example.com.

If your custom domain uses the “Use a third-party service or CDN to serve the domain” domain configuration option, the required configuration for that domain changes during these events.

• If your org uses Salesforce Edge Network, when your instance name changes (whether or not your org is on Hyperforce)
• When you upgrade to Hyperforce
• When your org moves to Salesforce Edge Network or stops using Salesforce Edge Network

As part of planning for those events, work with your third-party provider to update the target host name for your domain immediately after the change. Otherwise, your custom domain stops working.

To determine if you have a custom domain that uses that configuration option, visit the Domains page in Setup. 

To determine whether your org is on Salesforce Edge Network, visit the My Domain page in Setup. 

For instructions about setting the target host name for your custom domain that’s served by a third-party service or CDN, see the in the Point Your Custom Domain to Your Org with Your Target Hostname section of Prerequisites for a Custom Domain That Uses a Third-Party Service or CDN.

9. Do I need to update the hard-coded references in my CTI integrations if I am moving to a new instance?

If you are using Open CTI, and the CTI Adapter URL in your call center definition is hard-coded with your Salesforce instance (for example, https://c.na6-visual.force.com/apex/Softphone), your CTI integration will be impacted.

Please change this hard-coded reference to a relative URL (e.g. /apex/Softphone) to ensure your CTI integration continues to work after the moving to a new instance. To update this, you can navigate to the specific click path of the call center object: Setup > Call Centers.

If you are using the Salesforce Desktop CTI Integration Toolkit, this maintenance will not impact your CTI integration as the Toolkit does not allow hard-coded references.

10. Do I need to update my Email Thread IDs if I am moving to a new instance?

If you have created custom email thread IDs, you may be impacted following a move to a new instance. Otherwise, you will not be required to update existing email thread IDs generated by Salesforce after a move to a new instance (even if an old instance name is still referenced).

Review the following steps to correct a custom-generated email thread ID:
i. Update your custom formula to the following format: ref:_00D[XX][yyyyy]._500[AA][bbbbb]:ref
ii. Where yyyyy and bbbbb are the 10-char ID with the leading zeros stripped.
iii. Email Thread ID formats that are parseable by our system code are as follows, (yyyyy and bbbbb are the record ID without the leading zeros)

NOTE: that ref:00DXyyyyy.500Abbbbb:ref is the old format that is no longer used.

Salesforce may change the formats over time which is why customers should refrain from generating their own Thread IDs. With customized thread IDs, you may experience an issue with on-demand Email-To-Case (E2C) where new cases are being created and are not being attached to the original case with replies. Please do not create your own custom thread ID formats. We do not officially support custom formulas for case Thread IDs therefore recommend customers use the out-of-box Thread ID formula that Salesforce generates. For more information about why you should not create custom, review the article Use custom thread IDs with Email to Case.

11. Will customers still be able to access our partner portal from the old instance URL after we move to a new instance?

For approximately 30 days after moving to a new instance, customers should be able to access your partner portal using the old instance URL. After this 30 day window, the old instance login URL will be decommissioned. Prior to moving to a new instance, we recommend admins add a custom note under the "System Maintenance" message on their org’s partner portal directing customers to use the new partner portal URL following the move to a new instance. Admins may also choose to recommend customers update their login bookmarks with the new partner portal URL.

12. Will there be any impact to Web-to-Leads/Cases (W2X) after I move to a new instance?

If you have hard-coded references in your W2X, you will need to update them to relative URLs prior to moving to a new instance. If you do not update hard-coded references, you may experience unintended service disruptions to W2X following the maintenance. W2X will be queued and processed after the maintenance is complete.

13. Do remote site names need to be updated after I move to a new instance?

Yes. Hard-coded references in remote site names must be updated with the new instance name immediately after the maintenance.

If you don’t update hard-coded references in remote site names following the maintenance, you may experience unintended service disruptions to remote sites.

14. Will moving to a new instance affect Salesforce Mobile SDK?

Moving to a new instance may affect data on Salesforce Mobile SDK-created apps if users do not have the latest versions. We recommend that you update all Salesforce Mobile SDK-created apps and push these updates to all users in your org prior to the maintenance.

If users have the latest versions of all Salesforce Mobile SDK-created apps, moving to a new instance should not affect data within the apps.

​​15. What to do if I have a Salesforce Chat (formerly known as Live Agent or SOS) implementation?

If your webpage or certificates have a hard-coded reference to the Salesforce Chat server endpoint URL,an instance refresh, org migration, or site switch can impact your Chat functionality. To minimize impact, follow best practices and avoid any hard-coded references to the endpoint and ensure you update the endpoint URL in the Deployment code you copied from the Deployment page in Setup. The Deployment code we provide has the ability to redirect to the newly assigned server, but you should still update the endpoint immediately after the Refresh is complete. 

For more information about Salesforce Chat endpoints and what is meant by a hard-coded endpoint, review the article, Chat no longer works after server endpoint URL is updated.

16. What actions do I need to take for any Apex Web Services Generated WSDLs?

If you use WSDLs to generate code, all areas where you have employed the code will need to be checked for hard-coded references. All hard-coded references must be updated to a My Domain URL.  This will ensure that once you have fixed all hard-coded references to point to the new My Domain URL you will not have to perform this work again.