Adobe Sign Customer Support Resources

• The email of the sending user
• The original file being uploaded and/or the name of the library template used
  • Were fields added via the in-app authoring tool?
    
  • Were prefill fields used?
• A description of the recipient list
  • Number of recipients
  • Roles
  • Authentication types
• A description of the error/problem (Images if possible)
• Can the problem be reproduced and with what frequency?

• The email of the sending user
• The agreement name
• The time/date the agreement was sent
• The email address of the recipient
• At what point did the signing experience encounter the issue?
• If the error is related to a field:
  • How was the field applied (Authoring/PDF/Text Tag)?
  • What happend vs what you expected to happen?
  • A copy of the uploaded form or the name of the library template

• A copy of the uploaded document or the name of the library template
• The email of the uploading user
• A description of the issue vs what you are expecting
  • Images if possible  

• The API holders email address
• The sending users eamil address
• A screenshot of the API log with errors
  
• A list of any integrations being used (if applicable)

• The name of the Integration (Salesforce, Dynamics, etc)
• A description of the unexpected behavior or error message (Images if possible)
• A description of the workflow leading up to the error
• Transaction information (if available)

• The email of the user exhibiting the behavior
• The original file being uploaded and/or the name of the library template used
  • Were fields added via the in-app authoring tool?
    
  • Were prefill fields used?
• Detailed steps to replicate the issue
• A description of the error/problem (Images if possible)
• Can the problem be reproduced and with what frequency?
• Is there a transaction number?

Based on the GDPR requirement to obtain user consent prior to storing data on the users device, some users may experience one or more requests to enable cookies:

• Users accessing Adobe Sign from the locales enforcing GDPR are required to enable the core service cookies
  • Performance and personal advertising cookies can be enabled or disabled by clicking the Customize button
  • Cookies can be managed at any time by clicking the Cookie Performance link at the bottom right of all Adobe Sign web pages:

Whenever the root domain is different on a page redirect, the user is prompted to enable cookies again (for the new domain)

• Users in accounts migrating to the adobesign.com domain (from echosign.com) may have to configure their cookies twice, as each domain must place unique cookies
  • Accounts that migrate back to echosign.com may also have to re-enable cookies for that domain
    

Users can mitigate this problem by updating their bookmarks to point to the adobesign.com domain instead of echosign.com

When a company sets up a domain like “adobe.com” there are DNS records that point all calls to the adobe.com domain at one or more server IP addresses on the internet. There are also DNS records for email that point to the email server/s for that domain.

If Adobe Sign sent emails from our adobesign.com servers, but inserted a “from” email address with a domain that did not match those DNS records, the email domain in the "from" address would not resolve back to that domain’s email servers and the receiving email server would identify the email as spam (this is a common way to try to “trick” people into thinking they got an email from a “known good” sender).

As it is not possible to change the sending servers, it is not possible to change the "from" email value on the outbound emails to anything other than adobesign.com.

• Note: the ReplyTo value is the email address of the user that created the agreement, so replying to an Adobe Sign email will route back to the creating user

• For accounts that log cases in the Adobe Admin Console, click here
• Accounts that log cases in the legacy Adobe Sign portal:
  • Log in to Adobe Sign    
  • Mouse over your name in the upper-right corner and select My Profile from the pop-down menu
  • On your My Profile page, mouse over the question mark next to your Group Name
    • A pop-out ballon with the names of all administrators for your group is displayed (both group and account level)
      • Clicking any name opens an email with the address of that person automatically added

Webhooks that record too many failures in response will automatically disable themselves and notify the customer admin or webhook owner.

When these emails are delivered can be customized to better fit the customer need. Three settings govern this function:

• Warning threshold - How many hours have to pass after the first failure before a warning email is sent (Default is 36 hours)
  • After crossing the warning threshold, a warning email will be sent every time the webhook fails (until it is disabled).
• Max duration - How long should the webhook be allowed to fail (after the first failure) before it is deactivated (Default is 72 hours)
  • After crossing the max duration threshold, the webhook will be disabled upon the next failure and an email is sent
• Max failure count - How many times must the webhook fail (consecutively) before disabling the webhook (Default value is 1)
  • After crossing the max failure count threshold, the webhook is disabled and an email is sent
    

The timer and counter rest as soon as the webhook successfully replies.

Who the emails are delivered to is dependent on the scope of the webhook.

If the primary contact isn't available, the secondary contact is notified:

Contact your Success Manager (or open a Support case) to customize the notification thresholds.

When a document on a workflow falls out of scope, the workflow throws a Server error message when editing the workflow:

Senders attempting to use a workflow with this problem are provided an error message that indicates the workflow contains documents that are our of scope:

This error means the workflow has lost the authority to use one or more of the attached library templates. Most commonly this happens when the template access permissions are changed from allowing the account/group access to limiting access to the owner.  

Admins should cancel out of this error message rather than reload the page.

To correct the error:

• The owner of the template should edit the template permissions to be available to the account/group that the workflow is bound to
• The owner of the workflow can replace the template with one with the appropriate permissions.  To do this cancel out of the error condition above and proceed to edit the workflow and replace the document