Adobe Sign Technical Notifications 2021-2022

Search

Adobe Sign Template: W-4 (2022)

First Reported: January 2022

August 2022

The new IRS W-4 (2022) form, entitled W-4 2022 (Employee's Withholding Certificate), is expected to be added to the Adobe Sign library as part of the April 2022 release.

 

ACTION REQUIRED

The new W-4 form template has a new libraryDocumentId. If you use the existing template’s libraryDocumentId in your applications, you will need to update it.

The 2021 version is to be removed from the system in June 2022.

Any application/API using the legacy (ver 2021) form must be updated before June 1st to ensure no disruption to successful service.

To find the libraryDocumentId in an API-enabled account:

  1. Log in as an Account Admin
  2. Click on the Account tab > Adobe Sign API > API Information > click the link: REST API Methods Documentation
  3. In the GET /libraryDocuments section, click the OAUTH ACCESS-TOKEN button 
    • Enable the library_read:self scope
  4. Click the Try it out! button
  5. In the Response Body, locate the new W-4 2022 (Employee's Withholding Certificate) form template (not ver. 2021) to see the libraryDocumentId value.  
Obtain the docID

Note:

Customers that prefer to manage the tax form within their account library can download a fully tagged PDF here.

If you need more information, please contact your Customer Success Manager.

Two new webhooks added with the June 14th release

First Reported: June 2022

Removed From Current List: July 2022

Two new webhooks have been added in the June 14th release:

  • Agreement expiration updated (AGREEMENT_EXPIRATION_UPDATED) (Only available via REST v6 API POST /webhooks) - Triggers when an agreement's expiration date is updated.
  • Agreement signer name changed by signer (AGREEMENT_SIGNER_NAME_CHANGED_BY_SIGNER) - Triggered when a recipient changes their name when signing to be a different value than the name provided when the agreement was created.

Both webhooks are available.

The payload for the new webhooks can be viewed here >

Feature Release: Adobe Acrobat Sign – June 15th Release Completed

The feature release is complete, and all features are available.

Permission Update to Adobe Acrobat Sign for Microsoft Integrations on June 8th, 2022 completed

First Reported: June 2022

Removed From Current List: June 2022

On June 8th, 2022, Acrobat Sign migrated the notifications framework for the Microsoft Teams, Outlook, Word, and PowerPoint integrations from callbacks to webhooks. This will improve notification delivery and enable users to get all their Acrobat Sign document notifications in their preferred integration, regardless of where the document originated.

Now that the update is complete, end-users will be prompted to re-accept the Acrobat Sign permissions, including viewing, creating/editing, and deleting webhooks, before they may continue using the integrations.

Re-acceptance of the Acrobat Sign permissions is only required once and will apply to Acrobat Sign in all Microsoft 365 integrations. This permission is granted at the account level and must be accepted by end-users.

Please visit the appropriate help page below and review "Establishing the authenticated relationship" for additional information. For "live" Acrobat Sign assistance, log into your Acrobat Sign account and click on the "?" then "Contact Support" to see your support options. 

Microsoft permissions

Classic Access Code feature removed from service with the June 2022 release

First Reported: May 2022 - Updated June 2022

Removed From Current List: June 2022

The Access Code feature has been completely removed from the Acrobat Sign system with the June 2022 release when the classic Manage page was removed from service.  

Disruption of service for the Custom Workflow Designer scheduled for June 15th, 2022, completed.

First Reported: May 2022 - Updated June 2022

Removed From Current List: July 2022

The Custom Workflow Designer had a brief disruption of service to update the underlying code in conjunction with the June 15th major release.

Between 3 -3:30 pm Pacific Time, the workflow designer may have not allow users to create a new workflow or save a workflow that was being edited.

The use of workflows to generate agreements was not be impacted during this time.

End of support for the Microsoft Internet Explorer 11 and legacy Edge browsers as of December 31st, 2021

First Reported: April 2021

Removed From Current List: June 2022

By December 31, 2021, Adobe Sign will no longer formally support the Microsoft Internet Explorer 11 or Microsoft Edge Legacy browsers. We recommend that customers no longer access the Adobe Sign application with these browsers.  After December 31, 2021, customers using these browsers may have a degraded experience, and some features may cease to work.

The recipient's e-Sign page should continue to function properly on these browsers to avoid disrupting the recipient's workflows. We are committed to helping make this transition as smooth as possible.

Feature Release: Adobe Acrobat Sign – April 5th Release Completed

First reported: November 2021 - Updated: April 2022

Removed From Current List: June 2022

Adobe Acrobat Sign has completed the feature release scheduled for the first week of April 2022. No downtime was experienced during this release

The April 2022 release includes feature improvements for users and administrators, as well as resolutions to multiple customer-reported issues.  

New SSL Certificate -
In effect April 1st, 2022

First Reported: February 2022

Removed From Current List: June 2022

Acrobat Sign has released the new SSL Certificates on the morning of April 1st, 2022.
There is no change to the public key, underlying cryptographic protocols, or scheme.

 

ACTION REQUIRED

Use of the public key

  • If you have custom-built integrations with Acrobat Sign using either the SOAP or REST APIs, and if any of these integrations have ‘pinned’ the existing public key, no action is required.
  • If you are using Acrobat Sign’s SSL certificates for SSO, or if you’re pinning the certificate itself (or using other methods), you can find the new Acrobat Sign certificates in the Adobe Acrobat Sign System Requirements.
    • If your SSO configuration supports multiple public certs/chains, you can add the new certificates now and remove the old public cert/chain from your configuration after the April switch.
    • If your SSO does not support multiple public certs/chains, you will need to sync your SSL switch with Acrobat Sign on April 1st, 2022.  

The new SSL certificates are now active as of April 1st, 2022.

Minor Feature Release: Adobe Acrobat Sign May 3rd, 2022

First Reported: March 2022

Removed From Current List: June 2022

Acrobat Sign completed a minor feature release on May 3rd, 2022. No downtime was experienced during this release

The May 2022 release includes one feature improvement to allow knowledge-based authentication for additional participants in web forms. 

Tenant updated for the Acrobat Sign for Word/PowerPoint, Outlook, and Teams integrations

First Reported: March 2022

Removed From Current List: May 2022

On March 22th, 2022, Adobe Acrobat Sign updated the Acrobat Sign for Office 365 application tenant, the common application tenant for the Word/PowerPoint, Outlook, and Teams integrations.  

Starting at 10 am Eastern Daylight Time, administrators/users may have been prompted to re-accept a permissions request for the application before access is permitted. The exact time depends on when the account's  Microsoft-issued authentication token expires (up to 24 hours after the starting point).

Scheduled maintenance for the Adobe Sign Custom Email Templates (CEMT) Service - Completed

On Saturday, February 12th, 2022, from 6:00 p.m. PST to 7:00 p.m. PST, the Adobe Sign Custom Email Templates (CEMT) Service will have a brief degradation of service while core infrastructure components are upgraded. During this time, customers may see default mail templates instead of their expected custom templates. No outage is expected.

Feature Release: January 2022 - Completed

First reported: September 2021 - Updated:
January 2022		 Removed From Current List: March 2022

Adobe Sign has completed the January 2022 release with no downtime experienced in the application.

The January release includes feature improvements for users and administrators, as well as resolutions to multiple customer-reported issues.  

The new Home and Manage page become the standard in January 2022; Classic pages removed from service

First reported: September 2021 Removed From Current List: March 2022

Adobe Sign is retiring the classic experiences for Home and Manage pages in the January 2022 release. At that time, all accounts will be transitioned to the modern Home and Manage experience, with no option to revert to the classic interface.
Please note that we are committed to making this transition as smooth as possible, and have released features to match behaviors of the classic manage page, including:

  • Targeted search by first and last name.
  • Senders can now add a message when replacing the signer.
  • Added functionality to remind CCs and signers who have completed.

In the December release, we are further enhancing search capabilities and adding a ‘quick glance at metadata’ feature.  

Adobe Sign authentication redirects to Adobe Identity Management

First Reported: August 2020

Removed From Current List:
December 2021

Starting with the September Adobe Sign release, some users that authenticate directly to the Adobe Sign application will find their authentication method rerouted to the Adobe Identity Manager.

Adobe is standardizing authentication to this format throughout the end of 2020.

More details can be found here >

Feature Release: Adobe Sign October 2021

First reported: September 2021 Removed From Current List:
November 2021

Adobe Sign has completed the October 2021 release with no downtime experienced in the application.

The October release includes feature improvements for users and administrators, as well as resolutions to multiple customer-reported issues.  

Locking name values extended to typed signatures

First reported: August 2021 Removed From Current List:
November 2021

The March release introduced a setting to enable/disable a recipient's ability to edit their name value when signing, provided the name was supplied or known (via API or user profile). Typed signatures were excluded from this feature resulting in the ability for some signers to change their name value during the signature process. The September release updates this feature to honor the name locking setting for all signature types – including typed signatures.

  • Customers who have enabled Typing their name and initials and disabled Signers can change their name or initials will see a behavior change – the name value is no longer be editable during the signature process for typed signatures.
  • Customers that want to allow editing the name-value during the signature process should enable the Signers can change their name or initials setting (in the Signature Preferences menu).

Gated access to the e-Sign page in the September release

First reported: August 2021 Removed From Current List:
November 2021

To comply with Adobe Legal requirements, Adobe Sign is updating the terms of use (TOU) acceptance behavior on the e-Sign page. Under the new experience, all "unknown" recipients must accept the Adobe Sign TOU (by clicking the Continue button) before interacting with the agreement. This acceptance is distinct from any custom TOU that the customer account may have configured, which will continue to resolve per the account TOU/CD acceptance configuration.

  • An "unknown" recipient is any email address that is not a registered, active user email in a trusted account.
  • "Known" users have accepted the Adobe Sign TOU as part of the registration process when they verified their user account, so they are not prompted to accept again.

Below is an example of the Implicit consent flow for an agreement with a custom ToU configured by the customer:

  1. Accept the Adobe Sign ToU by selecting the Continue button (after opening the agreement).
  2. Fill in the agreement fields as required.
  3. Accept the Customer Disclosure and custom ToU by selecting the Click to Sign button.

API and Send page updates for the Notarize Integration feature (expected in October)

First reported: September 2021 Removed From Current List:
November 2021

The October release will introduce a new Adobe Sign feature to support integration with Notarize, Inc.'s Remote Online Notarization (RON) platform. The Adobe Sign integration with Notarize, Inc. is available for use in the U.S. only.

Below is the summary of changes:  

Notarize Integration - Adobe Sign integration with Notarize, Inc.'s Remote Online Notarization (RON) platform allows customers to add remote online notarization service as part of their Adobe Sign transactions. Available for enablement for customers in enterprise and business tiers sold directly by Adobe via the ETLA program. Notarize Transactions can be purchased as an add-on at an additional cost for these customers only. 

There are two elements that should be reviewed by customers building their own apps or using integrations: 

The Send page has a new element to identify a signer as requiring a notarized signature, and additional configuration steps to guide the signature process.  

The REST API has been updated to accommodate the requirements to leverage this functionality, and customers leveraging the REST API should review the below to determine if there is any impact for their existing use. 

  • Send Page updates

Customers with Notarize Transactions enabled can select the Requires notarization option on the recipient record, just to the right of the authentication method:

Notarize Interface on the Send page

After the agreement is configured and the sender clicks Next, the sender is presented with additional configuration options for the notarization process:

Configure Notarize options

  • API updates - There are significant updates to the APIs to support the Notarize Integration:

POST /agreements

The POST /agreements API has been updated to support sending an agreement for notarization.

  • A new role, NOTARY_SIGNER, should be used to indicate a notary session participant.
  • A new NotaryInfo attribute has been added to the AgreementInfo definition to contain all of the options associated with creating a new agreement that requires notarization.

Parameter Name

REST Object

Description

memberInfos

ParticipantInfo[]

Array of ParticipantInfo objects, containing participant-specific data (email, e.g.). All participants in the array belong to the same set.

role

Value

Description

SIGNER

Signs the Agreement

APPROVER

Approves the Agreement

DELEGATE_TO_SIGNER

One who herself can not sign but delegates the agreement to another signer

DELEGATE_TO_APPROVER

One who herself can not approve but delegates the agreement to another approver

SHARE

Participant with whom this agreement has been shared

DELEGATE

Participant to whom the Agreement was delegated. This role can not be used at the time of creating or updating agreement through POST/PUT call on agreement resource. Delegation happens separately by participants.

NOTARY_SIGNER

Notary Session Participant

Role assumed by all participants in the set (signer, approver, etc.)

 

FileInfo extension

The FileInfo definition will need to be expanded to indicate which documents should be notarized.

FileInfo

Parameter Name

Type

Default

Required

Description

document

Document

optional

A document that is associated with the agreement.
This field cannot be provided in POST call.
In case of GET call, this is the only field returned in the response

label  

String

optional

The unique label value of a file info element. In case of custom workflow this will map a file to corresponding file element in workflow definition.

libraryDocumentId

String

optional

ID for an existing Library document that will be added to the agreement

transientDocumentId

String

optional

ID for a transient document that will be added to the agreement

notarize

true

false

optional

Indicates that this document needs to be notarized.

 

ParticipantInfo extension

The ParticipantInfo definition has been expanded to allow the notary authentication method to be specified.

ParticipantInfo

Parameter Name

Type

Default

Required

Description

email

String

N/A

required

Email of the participant.

notaryAuthentication

Enum

MULTI_FACTOR_AUTHENTICATION

optional

MULTI_FACTOR_AUTHENTICATION - Notary authentication is performed using a two-factor authentication method
NONE - No authentication is required.

 

NotaryInfo

A new optional notaryInfo field has been added to the AgreementInfo definition to contain the NotaryInfo object that specifies additional options associated with notarization.

NotaryInfo

Parameter Name

Type

Default

Required

Description

notaryType

Enum

If only Notarize Notary on Demand Service is enable on the account,
then the notaryType will default to NOTARIZE_NOTARY, otherwise it will default to BYON_NOTARY

required

NOTARIZE_NOTARY - Notarize Service provides the notary
BYON_NOTARY - Account provides the notary

payment

Enum

BY_SENDER

optional

Only applies if type == NOTARIZE_NOTARY
BY_SENDER - Sender pays for the notarization
BY_SIGNER - Signer pays for the notarization

appointmentStart

String

""

optional  

ISO_DATE_TIME formatted string See ISO_ZONED_DATE_TIME

note

String

none

optional  

Notes for notary session.

notaryEmail

String

""

optional  

email of the bring your own notary

 

Example /agreement

{
    "fileInfos": [
        {
            "transientDocumentId": "{{transientDocumentId}}",
            "notarize": true
        }
    ],
    "name": "notary_agreement_name",
    "participantSetsInfo": [
        {
            "memberInfos": [
                {
                    "email": "someone@somewhere.com",
                    "securityOption": {
                        "notaryAuthentication": "MULTI_FACTOR_AUTHENTICATION"
                    }
                }
            ],
            "order": 1,
            "role": "NOTARY_SIGNER",
            "name": "participant_set_name"
        }
    ],
    "signatureType": "ESIGN",
    "state": "IN_PROCESS",
    "notaryInfo": {
        "appointment": "2021-10-29'T'13:00",
        "notaryEmail": "notaries@email.com",
        "notaryType": "PROVIDER_NOTARY",
        "note": "This is a note for the notary.",
        "payment": "BY_SIGNER"
    }
}

 

PUT|GET /agreements/{aid}

PUT /agreements/{aid} API will support updating an agreement with notarization options. GET /agreements/{aid} API will return any options set for agreement notarization. See POST /agreements section to view updated attributes.

 

Error Codes

Existing error codes for POST /agreements remain unchanged. We have defined a new error code as given below:

REST Error Code

HTTP Status Code

Message

Scenario

PERMISSION_DENIED

403

User setting or OAuth scope token do not permit sending agreement for notarization.

This error will be thrown when role is set to NOTARY_SIGNER and the API caller (i.e prospective sender) does not have notary feature enabled and/or if notary service provider is not set.

 

Documentation impact

In the request's AgreementInfo object, "status" element will include the new agreement status "WAITING_FOR_NOTARIZATION".

 

POST /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/signingTokens

The API can be used by customers (notary signers) to obtain a signing token that allows them to complete the esign phase of the flow. 

  • New signing capability has been added to capture the new role - ACCEPT_BEFORE_NOTARIZATION. 
  • Signing tokens should not be obtained to complete the notarization phase.
{
  "securityInfo": {
  "authenticationMethod": "NONE"
},
  "signingCapabilities": [
    "ACCEPT_BEFORE_NOTARIZATION"
  ]
}

 

PUT /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/status

The API can be used by customers (notary signers) to complete the esign phase of the flow. To accommodate the new role, new enum status value has been introduced - ACCEPTED_BEFORE_NOTARIZATION.

Attribute

Type

Description

Status

Enum<String>

Value

SIGNED

APPROVED

ACCEPTED

DELIVERED

FORM_FILLED

ACCEPTED_BEFORE_NOTARIZATION

                                         

This status indicates that recipient with role SIGNER completed agreement.

This status indicates that recipient with role APPROVER completed agreement.

This status indicates that recipient with role ACCEPTOR completed agreement.

This status indicates that recipient with role CERTIFIED_RECIPIENT completed agreement.

This status indicates that recipient with role FORM_FILLER completed agreement.

This status indicates that recipient with role NOTARY_SIGNER completed agreement without notarizing it

The notary signer can follow the below sequence of API calls to complete the esign phase:

  1. GET /agreements/{agreementId}/members - to fetch the notary signer's participant ID & participant set ID
  2. POST /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/signingTokens - to request signing token for notary signer with ACCEPT_BEFORE_NOTARIZATION capability
  3. POST /transientDocuments - to upload document that was reviewed
  4. PUT /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/status - to submit reviewed document and complete esign phase.

New webhook event

Customers can subscribe to new webhook event, AGREEMENT_READY_FOR_NOTARIZATION, to be notified when agreement is ready for notarization. The event is not visible on the webhooks UI & can be subcribed to via POST /webhooks API call.

Documentation impact

The following APIs are not modified but their documentation has been updated to include new agreement status "WAITING_FOR_NOTARIZATION" or new role "NOTARY_SIGNER".

GET /agreements

In response UserAgreements/UserAgreement object, "status" element now includes corresponding status "WAITING_FOR_NOTARIZATION".

GET /agreements/{agreementId}

In response AgreementInfo object, "status" element now includes corresponding status "WAITING_FOR_NOTARIZATION".

GET /agreements/{agreementId}/events

API is updated to support new READY_TO_NOTARIZE and NOTARIZED events.

In response Event object

  • "participantRole" element now includes new role NOTARY_SIGNER.
  • "type" element includes new events READY_TO_NOTARIZE and NOTARIZED. "description" element will be  "Document sent for notarization" and  "Notarized document received" respectively

GET /agreements/{agreementId}/members/participantSets/{participantSetId}

In response DetailedParticipantSetInfo object, "status" element now includes corresponding status "WAITING_FOR_NOTARIZATION".

PUT /agreements/{agreementId}

Request AgreementInfo object now includes "WAITING_FOR_NOTARIZATION" status.

PUT /agreements/{agreementId}/members/participantSets/{participantSetId}

WAITING_FOR_NOTARIZATION status is one of the "status" element values in the DetailedParticipantSetInfo object.

POST /agreements/{agreementId}/view

WAITING_FOR_NOTARIZATION status has been added as one of the allowed views.

GET /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/signingInfo

If the participant specified in request path has notary signer role, the API will return ACCEPT_BEFORE_NOTARIZATION signing configuration, inline with all of the other signing configurations for this agreement/participant.

Release: Adobe Sign September 2021

First reported: July 2021 Removed From Current List:
October 2021

Adobe Sign completed a feature release on September 16th, 2021. No downtime was experienced during this release

The September release includes feature improvements for users and administrators, as well as resolutions to multiple customer-reported issues.  

Company Name option to be removed from Phone Authentication

First reported: June 2021 Removed From Current List:
October 2021

SMS security (with regards to the sendingID matching the purported company name in the message) has improved to the point where Adobe Sign sending SMS messages with another company name can cause the message to fail in delivery.

As a result, the option to customize the phone authentication message with the company name is to be removed from service in the September 2021 release.


Known Issue: New Home or Manage page is blank

First Reported:  February 2020

Removed From Current List:
October 2021

Problem: When switching to the new Home or Manage page, the page is entirely blank.

Test: attempt to load this page: https://documentcloud.adobe.com/

  • If you can not load https://documentcloud.adobe.com/ then you should contact your internal network administration and work with them to unblock the documentcloud.adobe.com domain.
  • If you can access the above link, contact support

Adobe Sign v6 REST POST /workflows/ID/agreements has been removed from service

First reported: June 2021 Removed From Current List:
October 2021

The v6 REST POST /workflows/ID/agreements API call has been removed from service in the June 2021 release, one year after removing the call from documentation and notifying the users that the endpoint was to be removed.

Customers that continue to use this API call will now receive a 404 error.

The suggested alternative for replacing this functionality is to use a POST/agreement call with a workflowID in the JSON request.

Sample request body:

{
  "fileInfos": [
    {
      "transientDocumentId": "dsakjdfksajfkhaskdfuisdfklfsdkjfgvsdksjdkasj"
    }
  ],
  "name": "Sending a workflow",
  "participantSetsInfo": [
    {
      "memberInfos": [
        {
          "email": "someemail@somedomain.com"
        }
      ],
      "order": 1,
      "role": "SIGNER"
    }
  ],
  "workflowId": "woDJFWOFJhjlkadsfjkfdskfnksdfn"
  "signatureType": "ESIGN",
  "state": "IN_PROCESS"
}

v6REST Update for GET /agreements/{agreementId}/signingUrls

First reported: June 2021 Removed From Current List:
October 2021

Prior to the June release, when calling GET /agreements/{agreementId}/signingUrls, the API would return a 404 immediately after the agreement was created.

For a short time after the 404 error cleared, the response would return a non-404 response, but would only include the sender's signingURLs. (While the signer's participation was still being defined.)

After the June 2021 launch, a 404: AGREEMENT_NOT_EXPOSED code will be returned until the full list of signing URLs is completed, at which time a 200 code is delivered.

Customers that do not want to continue to try the API call until the 200 response is returned are encouraged to use Webhooks, and respond to the AGREEMENT_CREATED event.


Scheduled downtime for the Adobe Sign for Word/PowerPoint, Outlook, and Teams integrations

First Reported: March 2021 - Updated June 2021

Removed From Current List:
October 2021

On Saturday, July 17th 2021, Adobe Sign completed maintenance on the following integrations:

  • Adobe Sign for Microsoft Teams
  • Adobe Sign for Microsoft Word/Powerpoint
  • Adobe Sign for Microsoft Outlook

The integrations are now up and running normally.

Patch Release: Adobe Sign August 2021

First reported: June 2021 - Updated August 2021 Removed From Current List: September 2021

Adobe Sign has completed the patch update as of August 11, 2021. The patch was completed with no downtime.

The August patch release includes minor experience changes and resolutions to multiple customer-reported issues.  

Planned End of Service for the SOAP API in May, 2021

First Reported: June 2018 - Updated: February 2021

Removed From Current List: September 2021

With the release of REST API Version 6 providing the best programming experience for Adobe Sign developers, the SOAP API has been deprecated and will not be supported past May 2021.  The REST API is now the preferred interface to integrators and application developers and future development should move to this API.

Here are some references to help with the transition:

 

ACTION REQUIRED

If you have developed an integration or application to the Adobe Sign service based on the SOAP API you will have to rewrite your application using at least REST API Version 6 prior to May 2021.  Direct communications to developers and integrators will occur over the next several quarters to insure a smooth transition to the latest API.

Planned "End of Service" for IE 11 browsers in Microsoft integrations

First Reported: January  2021

Removed From Current List: September 2021

Microsoft is ending support for Internet Explorer 11 on August 17, 2021.

As a result, the Adobe Sign for Microsoft integrations are also ending support for IE11 on the same timeline.

Services impacted are:

  • Dynamics 365 (Online and On-Prem)
  • Microsoft 365
  • Outlook 365
  • Power Automate/Power Apps
  • SharePoint (Online and On-Prem)
  • Teams

For more information regarding the sunset of these browser options, see the Microsoft announcement >

Planned End of Service for Adobe Sign’s integration with Dropbox

First Reported: March 2021

Removed From Current List: August 2021

Adobe Sign’s integration with Dropbox is scheduled to end on July 31st, 2021.

At that time, Adobe Sign will no longer be available through your Dropbox account, however all of your Adobe Sign agreements will remain available to you and can be accessed by logging in to your Adobe Sign account.

New Release: Adobe Sign June 2021

Adobe Sign has completed the June 2021 release with no downtime.

The June release includes feature improvements for users and administrators, as well as resolutions to multiple customer-reported issues.  

New SSL Certificate Available -
In effect as of June 1st, 2021

First Reported: April 2021

Removed From Current List: August 2021

Adobe Sign is releasing new SSL Certificates on June 1st, 2021
There is no change to the public key, underlying cryptographic protocols, or scheme.

The new certificates are available by download from the Adobe Sign System Requirements page.

 

ACTION REQUIRED

Use of the public key
If you have custom-built integrations with Adobe Sign using either the SOAP or REST APIs, and if any of these integrations have ‘pinned’ the existing public key, no action is required.

If you are using Adobe Sign’s SSL certificates for SSO, or if you’re pinning the certificate itself (or using other methods), you can find the new Adobe Sign certificates in the Adobe Sign System Requirements.

The new SSL certificates will become active on June 1st, 2021

New W-4 for 2021 added to the Adobe Sign Library

First Reported: January 2021

Removed From Current List: July 2021 

The new IRS W-4 (2021) form, entitled W-4 2021 (Employee's Withholding Certificate), is expected to be added to the Adobe Sign library as part of the February 2021 release.

 

ACTION REQUIRED

The new W-4 form template has a new libraryDocumentId. If you use the existing template’s libraryDocumentId in your applications, you will need to update it.

The 2020 version is to be removed from the system in May 2021.

Any application/API using the legacy (ver 2020) form must be updated before May 1st to ensure no disruption to successful service.

 

To find the libraryDocumentId in an API-enabled account:

  1. Log in as an Account Admin
  2. Click on the Account tab > Adobe Sign API > API Information > click the link: REST API Methods Documentation
  3. In the GET /libraryDocuments section, click the OAUTH ACCESS-TOKEN button 
    • Enable the library_read:self scope
  4. Click the Try it out! button
  5. In the Response Body, locate the new W-4 2021 (Employee's Withholding Certificate) form template (not ver. 2020) to see the libraryDocumentId value.  
Obtain the docID

Note:

Customers that prefer to manage the tax form within their account library can download a fully tagged PDF here.

If you need more information, please contact your Customer Success Manager.

New Release: Adobe Sign May 2021

First Reported: March 2021

Removed From Current List: July 2021

Adobe Sign has completed the May 2021 release with no downtime.

The May release includes feature improvements for users and administrators, as well as resolutions to multiple customer-reported issues.  

Adobe Sign Cookie management update

First Reported: August 2020

Removed From Current List: July 2021

Adobe Sign is adopting a new cookie consent banner from OneTrust that is persistent until the user explicitly makes a choice.

Users that redirect to a new domain during authentication need to consent a second time for the second domain (The common case for this is redirecting from echosign.com to adobesign.com due to the domain switch). 

Users are advised to update their bookmarks to eliminate the redirect.

Fill & Sign has a path for templates and authenticated signing

First Reported: March 2020

Removed From Current List: July 2021

The Only I Sign compose page will be replaced by a new compose page (based on the latest Send page designs) that allow the use of templates and the placement of fields through authoring.

Admin settings determine the default user experience. An optional "switch" link can be enabled to allow the user to switch between the free form Fill & Sign interface and the new authoring-enabled Self-sign experience. 

New to this experience is the ability to employ authentication for the signer. 

The controls are based on the Enforce identity authentication settings. When enabled,  the user will be prompted to enter their Adobe Sign credentials when opening the agreement, and (optionally) again when they place a signature or finalize the agreement. 

The controls for the new self-signing experience, as well as enforced identity authentication, can be set at the account and/or the group level (group-level settings over-ride the account-level settings)

 

Rollout plan

The new self-signing experience will replace the legacy Only I Sign page over the next two major releases. 

Customers that are using the legacy Only I Sign capability should plan to migrate to the new experience by Fall 2020 when it becomes the default and the legacy page is removed from service. 

  • No changes to the existing settings will be made with the July release
  • In the following release, the new experience will be set as the default with the option to revert to the old page
  • In the Fall 2020 release, the ability to revert to the legacy interface will be removed.

The Adobe Sign for Word/PowerPoint, Outlook, and Teams update goes live April 19th

First Reported: December 2020 - Updated: March 2021

Removed From Current List: May 2021

The update will go into effect at 8:00AM PDT / 11:00 EST / 15:00 UTC

This update is being put in place to enhance overall security across all three integrations.

After the update is completed, administrators/users will be prompted to re-accept a permissions request for the application before access is permitted.

Details can be found here >

New Release: Adobe Sign March 2021

First Reported: February 2021

Removed From Current List: May 2021

Adobe Sign has completed the release for March 2021 with no downtime.

This product release includes new features/enhancements for administrators and end-users as well as multiple resolved issues.

Planned "End of Service" for Edge Legacy browsers in Microsoft integrations

First Reported: January  2021

Removed From Current List: May 2021

Microsoft is ending support for the Edge Legacy browser on March 9th, 2021

As a result, the Adobe Sign for Microsoft integrations are also ending support for Edge Legacy on the same timeline.

Services impacted are:

  • Dynamics 365 (Online and On-Prem)
  • Microsoft 365
  • Outlook 365
  • Power Automate/Power Apps
  • SharePoint (Online and On-Prem)
  • Teams

For more information regarding the sunset of these browser options, see the Microsoft announcement >

End of Support: The Adobe Sign for Microsoft Power Automate v1 Actions- scheduled for January 2021

First Reported: July 2020

Removed From Current List: May 2021

Adobe Sign for Power Automate 3.0 update introduces new REST v6 Actions that are intended as more robust replacements for existing actions of the same name.

Workflows using legacy actions will continue to run if no action is taken. The legacy actions have been marked with (Old) in their name.  These legacy Actions are scheduled to be deprecated by January 2021.

The list of Actions to be deprecated is:

  • Create a library template from a document URL (Old)
  • Create a library template from an uploaded document (Old)
  • Create an agreement from a document URL and send for signature (Old)
  • Create an agreement from a library template and send for signature (Old)
  • Create an agreement from an uploaded document and send for signature (Old)
  • Get a list of all agreements (Old)
  • Get a list of all library templates (Old)
  • Get form field data of agreement (Old)
  • Upload a document and get a document ID (Old)

 

The new actions show in the Actions list with the same name as the legacy Actions.

Customers that use these Actions should update their flows to use the new connector Actions. This can be done by replacing the Legacy action with the new Actions in your existing automation flow.

End of Service for Social Authentication

First Reported: November 2020

Removed From Current List: May 2021

The ability to require signers to provide their social identity before they gain access to view and sign the document will be removed in March 2021.  This feature enabled Senders to require a sign-in from Facebook, LinkedIn, Google, Yahoo!, Microsoft Live or Twitter. 


Planned "End of Service" for the personal Twitter integration

First Reported: December 2020 - Updated: January 2021

Removed From Current List: May 2021

The option to integrate with Twitter at the User level (via Personal Preferences) is to be removed from the user interface in March 2021. At that time:

  • No new user accounts can enable Twitter at the User level
  • Users that have Twitter enabled will stop seeing Twitter messages for new agreements created
  • Free user accounts that have Twitter enabled will have the monthly transaction limit reduced from ten to:
    • 5 transactions per month for Adobe Sign Web clients
    • 2 transactions per month for Acrobat clients
  • Enabled accounts will have their Twitter credentials removed from the Adobe Sign systems
  • Adobe Sign's Twitter app will be deleted to expire all Twitter tokens
12.2Twitter

New Release: Adobe Sign February 2021

First Reported: January  2021 - Updated: February 2021

Removed From Current List: March 2021

The  February release has been completed with no downtime to the service.

This product release includes new features/enhancements for administrators and end-users as well as multiple resolved issues.

Workflow Designer producing error messages

First Reported: September 2020

Removed From Current List: March 2021

Due to improved security around the sharing of library assets, some workflows may start throwing a Server error message when editing the workflow after the September update:

Workflow designer error

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

Workflow error when sending

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

End of Service for Adobe Sign for Workplace by Facebook

First Reported: November 2020

Removed From Current List: January 2021

The Adobe Sign for Workplace by Facebook integration has being fully decommissioned as of  November 29th, 2020.

Adobe logo

Sign in to your account

Quick links

View all your plans Manage your plans

Legal Notices    |    Online Privacy Policy