Migrating from echosign.com to adobesign.com

Admins that have users leveraging the Acrobat Sign for iOS mobile app should alert their users to upgrade their app version to 3.22 or later.

The Acrobat Sign for Android app is not impacted by the domain change.

If your account uses any custom email templates, the template must be updated to allow for a reference to adobesign@adobesign.com as the email alias for users to add to their safe list..

• To do this, the fixed string echosign@echosign.com is changed to the variable $!from@$!active_domain
  • This allows the address to dynamically change when the account is switched between domains

Customers that actively restrict email should explicitly allow email from adobesign@adobesign.com

• If you have an existing rule to allow echosign@echosign.com, then add this new rule also
  • Do not remove the echosign@echosign.com rule at this time
    

Failure to do so could result in inbound (email) agreement notifications being filtered out to spam/junk folders.

Customers with restrictive network security should explicitly allow traffic from the new domain's production endpoints.

If your current network permissions are configured to allow echosign.com traffic through, the adobesign.com endpoints should be added as well.

• Do not remove the echosign.com endpoints at this time
• Only add adobesignforsalesforce.com if your account employs the Adobe Acrobat Sign for Salesforce integration
• Customers that have accounts on the Demo environment should add the adobesign Demo endpoints as well
  

Accounts that leverage the API service should review their code to ensure that it also supports the adobesign.com domain.

• Ensure your network security for the new domain is in place to allow the traffic through
• Example API Request/Response
  

Customers/Partners/Integrators may have code that has a hardcoded check for the URI returned. This may be done as a security measure to prevent an exploit which attempts to redirect the domain incorrectly.

• Contact the owner of any third party integration to determine if this situation exists
• Contact your internal stakeholders for custom integrations that were built in-house

Adobe Acrobat Sign for Salesforce customers must relink the OAuth connection between Acrobat Sign and Salesforce (as soon as possible) after the domain has been changed.

Changing the domain breaks the trusted connection between Acrobat Sign and Salesforce. Until the OAuth link is reconnected:

• Users will not be able to send agreements from Salesforce
  • Attempts to send will prompt an error and save the agreement as a Draft   
    
• Updates will not be pushed back into Salesforce
  • Upon reconnection, the agreements can be updated and resynced with the Acrobat Sign service
    

Review/Update Remote Site Settings

Organizations that have configured Remote Site Settings for Acrobat Sign must also update the remote site URL to reflect adobesign.com (in place of echosign.com).

Repeat steps 3-5 for all remote sites that use echosign.com as the domain for the URL.

Note that it is possible for the site URL to contain the string "echosign" in a location of the string that is not the domain. Do NOT edit these values:

Existing web forms will continue to work as expected after changing the domain.

When a web form is created, it is identified by a unique webformId (wid).

Changing the domain changes the URL of the web form, but not the webformId.

Example:

The echosign.com webform URL:

• https://caseyjonez.na1.echosign.com/public/esignWidget?wid=CBFi_MHTdBzgM82U*

The same web form after the domain change:

• https://caseyjonez.na1.adobesign.com/public/esignWidget?wid=CBFi_MHTdBzgM82U*

Because Acrobat Sign continues to accept inbound traffic on the echosign.com domain, the URL resolves and the correct webformId is delivered.