Migrering fra echosign.com til adobesign.com

Administratorer, der har brugere, som bruger mobilappen Acrobat Sign til iOS, skal advare deres brugere om at opgradere deres appversion til 3.22 eller senere.

Appen Acrobat Sign til Android påvirkes ikke af domæneskiftet.

Hvis din konto bruger en brugerdefineret mailskabelon, skal skabelonen opdateres for at tillade en reference til adobesign@adobesign.com som mailaliasset for brugere at føje til deres liste over sikre mails.

• For at gøre dette ændres den faste streng echosign@echosign.com til variablen $!from@$!active_domain
  • Dette gør, at adressen skifter dynamisk, når kontoen er skiftet mellem domæner

Kunder, der aktivt begrænser mail, skal eksplicit tillade mail fra adobesign@adobesign.com

• Hvis du har en eksisterende regel om at tillade echosign@echosign.com, skal du også tilføje denne nye regel
  • Fjern ikke echosign@echosign.com-reglen på nuværende tidspunkt
    

For ellers kan det resultere i, at indgående (mail) aftalenotifikationer filtreres fra til spammapper.

Kunder med begrænset netværkssikkerhed bør eksplicit tillade trafik fra det nye domænes produktionsslutpunkter.

Hvis dine nuværende netværkstilladelser er konfigureret til at tillade echosign.com-trafik, bør adobesign.com-slutpunkterne også tilføjes.

• Fjern ikke echosign.com- slutpunkterne på nuværende tidspunkt
• Tilføj kun adobesignforsalesforce.com, hvis din konto bruger Adobe Acrobat Sign til Salesforce -integrationen
• Kunder, der har konti på Demo-miljøet, skal også tilføje adobesign Demo-slutpunkter
  

Konti, der anvender API-tjenesten, bør gennemgå deres kode for at sikre, at den også understøtter adobesign.com-domænet.

• Sørg for, at din netværkssikkerhed for det nye domæne er på plads for at tillade trafik igennem
• Eksempel på API-anmodning/-svar
  

Kunder/partnere/integratorer kan have kode, som har en "hard coded" kontrol for den URI, der returneres. Dette kan gøres som en sikkerhedsforanstaltning for at undgå en exploit, der forsøger at omdirigere domænet på forkert vis.

• Kontakt ejeren af en tredjepartsintegration for at afgøre, om denne situation findes
• Kontakt dine interne interessenter for brugerdefinerede integrationer, der blev bygget internt

Adobe Acrobat Sign til Salesforce -kunder skal gendanne OAuth-forbindelsen mellem Acrobat Sign og Salesforce (så hurtigt som muligt) efter domæneskiftet.

Domæneskiftet bryder den pålidelige forbindelse mellem Acrobat Sign og Salesforce. Indtil OAuth-forbindelsen genoprettes:

• Brugere kan ikke sende aftaler fra Salesforce
  • Forsøg på at sende vil udløse en fejl og gemme aftalen som en Kladde.
    
• Opdateringer skubbes ikke tilbage til Salesforce
  • Efter forbindelsen er blevet genoprettet, kan aftalernes opdateres og gensynkroniseres med Acrobat Sign -tjenesten
    

Gennemgå/opdater Indstillinger for fjernwebsted

Organisationer, der har konfigureret Indstillinger for fjernwebsted for Acrobat Sign, skal også opdatere URL'en til fjernwebstedet, til adobesign.com (i stedet for echosign.com).

Gentag trin 3-5 for alle eksterne websteder, der benytter echosign.com som domæne for URL'en.

Bemærk, at det er muligt for websteds-URL'en at indeholde strengen "echosign" et sted i den streng, som ikke er domænet. UNDGÅ at redigere disse tre værdier:

Eksisterende webformularer fortsætter med at virke som forventet efter domæneskiftet.

Når en webformular oprettes, identificeres den med en unik webformId (wid).

Skift af domænet ændrer webformularens URL, men ikke webformId.

Eksempel:

Echosign.com webformular-URL:

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

Den samme webformular efter domæneskiftet:

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

Da Acrobat Sign fortsat accepterer indgående trafik på echosign.com-domænet, oversættes URL'en, og det korrekte webformId leveres.