Issue key
Last updated on
Mar 20, 2022
Adobe Sign Release Notes: 2021
Adobe Sign: March 2021
Improved Functionality
Multi-signer web forms
Accounts that use Web Forms now have the ability to allow for multiple external recipients in the signature process.
Additional recipients are defined by the initial signer:
Use Library Templates to create Web Forms
Authors can now use existing Library Templates to create new Web Forms. The file is imported with all fields intact:
"Liquid Mode" in Adobe Sign for Mobile Viewing
Liquid Mode is an optional feature for generating a responsive view so you can improve the display of your documents based on the signer's device type.
The signed document is stored in the standard "PDF" version while the recipients can see the Liquid Mode on mobile phones and can toggle to view the original document.
You can now upload your HTML document and generate a Liquid Mode view for mobile phones.
Lock the Name value for known users when signing via Image or Drawn signature methods
There are situations where the ability to change the name of the recipient during the signing ceremony is undesirable. Adobe Sign has provided flexibility in this regard in deference to the name preference of the Signer. In more compliant environments this flexibility is unacceptable so there is a new control to lock the names of the recipients to the agreement.
Admins now have the ability to prevent recipients with known Name values from changing those values when they apply a Drawn or Image signature.
Situations where the name value is known:
- When sending to a recipient with an Adobe Sign ID
- When sending the name through the API
- When the Signer Info fields are completed during form filling
- When the name is locked during the completion of a KBA or Government ID authentication
Improvements to Knowledge-based Authentication
Controls have been added to the KBA method of identity authenticaiton that can require the sender to provide a Name for the recipient and that Name value is locked in place through the signature process.
Options for enhanced email security
Two new options are available to improve email security. Both settings are enabled by default:
- Include a link in emails to view the signed agreement
- Include an image of the first page of the agreement in emails
- Enabled by default
- When enabled, an image of the first page of the agreement is visible in some email distribution
v6 REST API Updates
STANDARD HEADERS IN EVERY V6 REST API REQUEST
By default, every v6 REST API request now has the below standard headers:
/AGREEMENTS
All /agreements endpoints that have an agreement id path now return a 404 AGREEMENT_DESTROYED error code if the agreement has been deleted via GDPR tools.
LIBRARY TEMPLATES
PUT /libraryDocuments/{libraryDocumentId} - Expanded to include the new field ownerId
Note:
Only the v6 REST API is impacted.
Any v6 REST API call that does not include these headers will explicitly document that absence.
- GET /libraryDocuments - Expanded to include the new field ownerEmail
- GET /libraryDocuments/{libraryDocumentId} - Expanded to include the new fields: ownerId, ownerEmail, and ownerName
New fields in LibraryDocumentInfo object:
Fields with updated behaviour:
WEB FORMS (/WIDGETS)
- POST /widgets - Using a libraryDocumentId to create a web form is now supported with a valid id
Added status code:
- PUT /widgets - Using a libraryDocumentId to create a web form is now supported with a valid id
Added status code:
- PUT /widgets/{widgetId} - Expanded to include the new field ownerId
Added status code:
Experience Changes
- GET /widgets/{widgetId} - Expanded to include the new fields: ownerId, ownerEmail, ownerName, and creatorName
New fields in WidgetInfo object:
Fields with updated behaviour:
/MEGA SIGN
NEW:
- GET /megaSigns/{megaSignId}/formFields - Retrieves the form field details of a Mega Sign parent agreement
Parameters:
Response object:
- PUT /megaSigns/{megaSignId}/formFields - Updates the form fields of a Mega Sign agreement
Parameters:
Response object:
UPDATED:
- POST /megaSigns - AUTHORING has been added as a state value to support authoring a Mega Sign template
Changed Parameter:
- PUT /megaSigns/{megaSignId}/state - AUTHORING has been added as a state value to support authoring a Mega Sign template. As a result, megaSignCancellationInfo is no longer a required field
The modern Home and Manage page has been enabled for all remaining accounts
All accounts have had their control set updated to enable the modern Home and Manage pages for their users.
The controls in the admin menu remain available for accounts that must revert to the classic experience:
Adobe Sign service level and account ID exposed in Admin menu
Admins can now find their Account ID on the Global Settings page:
The Group ID can be found on the Group Settings page:
Explicit HIPAA configuration
There's a new page available that clearly shows when the account is enabled to manage agreements subject to HIPAA requirements.
- This control is only exposed at the account level. Group-level admins do not have access
- This control is view only, to clearly indicate when the account is configured
- Contact your success manager or support to enable HIPAA configuration
The "Call to action" button has changed for customers using the Outlook Desktop application on Windows systems
Recipients that use an Outlook Desktop email client will see a change in the "call to action" button on Adobe Sign emails.
The new experience removes the blue HTML button, and instead supplies a clickable text link:
Note:
This change only impacts Outlook Desktop apps on Windows systems. Other email clients and operating systems continue to receive the template with the blue button.
Delegation of agreements with digital signatures
The ability to delegate an agreement with digital signatures affixed has been improved to allow delegation from the original email notification to the recipient, through automatic delegation when configured by a user, and through the Replace Current Signer action on the Manage page.
Updated interface for the Payments integration
The Payments interface has been updated to have the authenticating controls better exposed, creating an easier configuration process.
The maximum value for Data Governance has been increased to 5475 days (15 years)
Customers that use data governance rules to automatically delete agreements from the Adobe Sign system can now set that deletion date to a maximum of 15 years (up from ten).
The field level text label for validating the US Social Security Number has been updated:
The field level text label for validating the US Social Security Number has been updated to clarify the SSN is US predicated:
Reminder: Social Authentication has been removed
As announced in November, the authentication method using social identity has been removed from the list of authentication methods in the Admin menu.
Reminder: Personal Twitter integration has been removed
As announced in December, the Users' ability to make personal authenticated connections to Twitter has been removed.
Inactive users will receive an email notification when included in an agreement
Users that are set to an Inactive status now receive an email notification instructing the recipient to delegate the agreement to another user.
Resolved Issues
Adobe Sign: May 2021
Improved Functionality
Transfer the ownership of library templates and web forms to a different user
Changing the owner of an asset can now be done by any administrator in the account that has access to the asset.
The administrator can assign the asset ownership to any user under their authority.
- Account admins have access to all shared assets and all users. Therefore, account-level admins can reassign the ownership of any library template or web form to any other user in their account
- If the asset is configured to only be available to one user (the owner), it is not shared and therefore unavailable to reassign to a new owner
- Group administrators can only access library templates and web forms within the groups where they have administrator authority
- Group administrators can only reassign an asset to a user whose primary group falls under their administrative authority
UPDATED API ENDPOINTS SUPPORTING ASSET TRANSFER
The endpoints described below are only available in the v6 REST API.
Extended to support update of library document owner.
LibraryDocumentInfo:
Additional Error Status Codes:
Additional Error Status Codes:
New fields in LibraryDocument object:
New fields in LibraryDocumentInfo object:
Fields with updated behavior:
New fields in WidgetInfo object:
Fields with updated behavior:
Experience Changes
The default v6 REST GET /workflows{workflowId} return value has changed
The v6 REST GET /workflows{workflowId} API call has been updated to return the current version of the WorkflowID (vs. the original version ID, which was the returned value prior to the May release)
This update aligns the default API experience with the Webhook experience, providing the same WorkflowID, which should improve the development and management of applications.
If, for any reason, your account requires the API to return the original ID (as it did prior to the May release), contact support to request that your account return the base version IDs for workflows
Resolved Issues
Adobe Sign: June 2021
Users in Multiple Groups (UMG)
Administrators in multiple group accounts can now grant Users within their account access to multiple Groups, opening the option to utilize groups as a form of workflow template, enforcing specific sending and signing controls for the library templates available to the group.
Existing enterprise and business accounts that would like to upgrade can review the upgrade process here >
A summary of the impactful differences can be found here >
Introducing Liquid Mode in Sign
Enable Liquid Mode view for mobile phones for HTML sent via Send Page or sendAgreement API. The option to enable Liquid Mode in Sign for HTML is now available in the Admin menu list at both the account and group level.
Full details on Liquid Mode documents can be found here >
Note:
Liquid Mode is currently available only on the NA1, NA2, and NA4 environments.
Seamless web form updates
Web forms in Draft status can be edited to alter:
- the Web Form Name
- the email address of the counter-signer(s)
- the email address of the CC'd parties
- the attached files to be edited
- the fields on the web form (previously available)
Updating an Active web form allows for editing the form elements without changing the original URL, allowing for a frictionless process if you need to update the content of a web form that has already been embedded or sent to your audience. Elements that can be edited are:
- the files (documents) and applied fields for the recipients
- counter-signers (from the Manage page)
- CC'd parties (from the Manage page)
Note:
To enable seamless web form functionality, you must enable the Allow additional participants option in the Global Settings menu:
Participation Stamp: Control Title and Company Display
Controls have been added to allow or suppress the recipient Title and Company (derived from the user profile) on the participant stamp field.
Further details can be found on the Field Types page >
Improved search options: Prefix and Phrase matches
Advanced search options have been introduced to allow for more specific search patterns that will help reduce the returned agreement list.
Further details on how Searching works in Adobe Sign can be found here >
OAuth 2.0 is the new default
A new (improved) version of the OAuth endpoint has been added to avoid usage mistakes. With this version:
- api_access_point / web_access_point returns only in the Access Token Request (in the body)
- Adobe Sign doesn’t accept the secret as a query parameter
- Client secret rotation is supported
The OAuth v1 endpoint will continue to work for existing connections over the next several months to ensure continued access.
The deprecation of OAuth v1 will be announced on the Technical Notifications page once scheduled.
Client Secret Rotation
Application Client Secrets can be rotated by any admin with access to the application ID in the Adobe Sign UI:
Experience Changes
Group Administrators can only see the API applications that fall under their admin authority
The visibility of applications attached to the account is now constrained only to show the applications that fall under the administrative scope of the user. Only Group admins will see the behavior change:
- Users see the applications they own
- Group admins see the apps under the group(s) they have admin authority over
- Account admins see all applications in the account
Email to the sender when an agreement is complete has been updated
The final email notification for an agreement sent to the sender has been updated to provide a comprehensive list of all parties notified about the completed agreement.
Only the original sender will get this email template.
Updated v6 REST API Result for GET /agreements/{agreementId}/signingUrls
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.
Resolved Issues
Adobe Sign: August 2021
Experience Change
- Aadhaar International Support – Customers from all Adobe Sign instances can now use the optional Aadhaar service as a digital signature provider. Previously it was only available to accounts on the IN1 instance. The Aadhaar add-on can be purchased at an additional cost per signature transaction.
- REST v6 Update: POST /users - The REST v6 POST /users API call has been updated to create the user in the account's Default group if the optional primaryGroupId parameter is not defined. Only the v6 of the REST API is impacted by this change.
Resolved Issues
|
|
Description |
|---|---|
|
4299495 |
Fixed an issue in the Workflow Designer that would prevent a customer-defined URL in the instructions not to work. |
|
4308294 |
Corrected an issue in the Report CSV file where the To and Recipient Name fields could be left empty when the same recipient email is used more than once in the agreement. |
|
4310569 |
The Adobe Sign templates have been filtered out of the sandbox options. |
|
4311098 |
Corrected an issue where Group Admins could not update users in a group by CSV upload. |
|
4311723 |
Fixed an issue where the GET /groups/ID/users API call would fail if the user was on a different Adobe Sign instance. |
|
4312103 |
Corrected an issue where SAML users created via bulk upload would be in a Created state (instead of Active). |
|
4312309 |
Corrected an issue where group admins could not reassign ownership of Web Forms if other users in their group created them. |
|
4312840 |
Fixed an issue with activating new users when a second activation email was sent to the new user and that second email link was used. |
|
4314751 |
Corrected an issue where the option to Decline the Agreement was not visible when Signing on Behalf of another user. |
|
4315033 |
Fixed an issue where account administrators could not reset passwords when SAML mode was set to Mandatory. |
|
4315605 |
Corrected an issue where Government ID images would not successfully process. |
|
4316057 |
Corrected an issue where Government ID would produce an error indicating the four corners of the document could not be found. |
|
4316474 |
Corrected an issue where Sign on Behalf Of was visible in accounts where the option was not enabled. |
|
4316659 |
Fixed an issue where the email address for 'actingUserEmail' in a GET /agreements/id call would return a system-generated email after the agreement was fully signed. |
|
4317095 |
Corrected an issue where a recipient name would be imported into the Participant 1 label when Knowledge-based Authentication was used for the first signer. |
|
4317221 |
Corrected an issue where automatic notification emails for failing webhooks would be sent to the webhook creator despite being configured not to notify the creator. |
|
4317347 |
Corrected an issue where authentication of OAuth in Power Automate would redirect the user to the home page. |
|
4317429 |
Fixed an issue where admins could not update the Can Send property for users when updating via CSV upload. |
|
4317548 |
Fixed an issue where some customers using the iPad would see the web page instead of the page optimized for mobile devices. |
|
4317629 |
Fixed a display issue with names that contain an apostrophe displaying the HTML code for the apostrophe. |
|
4318175 |
Corrected an issue where users would get an error when archiving an account via the email link. |
|
4319012 |
Fixed an issue where users created via REST v5 and v6 POST /users were not created in the default group. |
|
4320197 |
Fixed an issue where the Signer Identity Report could not be downloaded from the Manage page due to the button being inactive. |
Adobe Sign: September 2021
Improved Functionality
- Sandbox - Enterprise tier customers have the option to purchase access to a Sandbox environment to test templates, customer workflows, API applications, and more. These objects can be moved from production to the sandbox for updates in a safe environment, then moved back to production once the updates are verified and ready for deployment.
- ECDSA Digital Signature Support - Adobe Sign now supports more secure and efficient digital signatures based on the ECDSA format, which uses elliptic curve cryptography as defined in the ANS X9.62-2005 standard.
NIST curves with SHA-2 hash functions, as defined by FIPS standards, are now supported, giving our Trust Service Providers (TSP) partners from the Cloud Signature Consortium the option to provide signers with faster and safer elliptic curve credentials, including those meeting the recommended requirements for US Federal and Singapore Government use.
- Liquid Mode Updated -The Liquid Mode signing experience has been extended beyond agreements to include web forms. Liquid Mode forms can dramatically improve the signer's experience by reducing the need to pinch and zoom to view the form content while improving the focus on fields that need to be filled.
Additionally, Liquid Mode is no longer restricted to North American shards. All enterprise and business accounts now have access regardless of location.
- New TSPs - Cleverbase (Netherlands), PrimeSign (Austria), Sectigo (Global), and TrustPro (Ireland) are the new Trust Service Providers from the Cloud Signature Consortium providing certificates to apply secure digital signatures that meet the highest standards and compliance requirements.
- Customize the To and CC fields in email headers to recipients - Customers that are concerned about leaking email addresses via the email headers to recipients can opt to hide the email address values in the To and CC fields.
- This option is available to enterprise and business tier accounts and can be configured at the account and group levels.
- The feature controls can be accessed by navigating to Account Settings > Email Settings > Customize To and CC fields.
Experience Changes
- Adobe Terms of Use Acceptance on eSign pages - To comply with Adobe Legal requirements, Adobe Sign is updating the terms of use (ToU) acceptance behavior on the eSign page. Under the new experience, all "unknown" recipients must accept the Adobe Sign ToU and Privacy Policy (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:
- Accept the Adobe Sign ToU by selecting the Continue button (after opening the agreement).
- Fill in the agreement fields as required.
- Accept the Customer Disclosure and custom ToU by selecting the Click to Sign button.
- Locking name values extended to typed signatures - 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 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).
- Inactive users can sign agreements - Adobe Sign is now treating Inactive users as if they are unknown to the system (for the purpose of signing in-bound agreements). When an Inactive user is asked to sign an agreement, a new, single-use userID is created expressly for the purpose of signing that one agreement. The single-use userID is independent of the Inactive userID, and the account which governs it. This has several ramifications:
- Agreements sent to an Inactive user can be signed, as the Inactive status does not apply to the single-use userID generated for the agreement.
- Agreements signed by the single-use userID are not assets of the Inactive userID and do not reside in the account of the Inactive userID.
- Shares from the Inactive userID will not reflect agreements signed by single-use userIDs.
- Reporting against the Inactive userID will not reflect agreements signed by the single-use userID.
- If the Inactive userID is reactivated, they will not see the records of the agreements signed by the single-use userIDs on their Manage page.
There are two exceptions to the above behavior:
- Agreements sent to the user before they were flagged as Inactive may not be signed (the agreement was already bound to the Inactive userID).
- Users explicitly configured to not be allowed to sign agreements will continue to be disallowed any signing actions.
Inactive users are still prevented from logging in to the Adobe Sign system and sending agreements under their authority (by any method).
- Improved security for web form access via password - Web forms have included a delay after a number of unsuccessful attempts to access a password-protected URL.
- Aadhaar International Support – Customers from all Adobe Sign instances can now use the optional Aadhaar service as a digital signature provider. Previously it was only available to accounts on the IN1 instance. The Aadhaar add-on can be purchased at an additional cost per signature transaction.
- Limited sharing of agreements - Agreement sharing has been capped when sharing the agreement to an external email address.
- Multi-license accounts can share any one agreement up to ten times.
- Individual accounts can share an agreement up to 5 times.
- Sharing an agreement with internal users is unrestricted.
- Multi-license accounts can share any one agreement up to ten times.
- Custom Company Name in Phone Authentication has been removed from service - The customizable company name value that could be inserted into the Phone Authentication method has been removed from service as announced in the June Technical Notification.
- HIPAA-enabled accounts can now access the controls for images and links in recipient emails on the Global/Group Settings page.
- The order that File Attachments are included in the final PDF has been updated to sort by page number first, and then field position second (when reading left to right; top to bottom)
- The Replace Recipient feature on the new Manage page now allows the sender to include an optional message for the new recipient.
- External signers accessing completed agreements now must pass an authentication process when multi-factor authentication has been configured for the agreement (instead of being prompted to log in to Adobe Sign).
- Web forms now report the field values of unverified web forms when accessing field data using the Download Form Field Data feature on the Manage page.
API Updates
- Read Agreement option for web forms - Two new REST v6 API calls are available to provide access to view web forms:
- GET /widgets/<resourceId>
- GET /widgets/<resourceId>/combinedDocument/url
- GET/workflows/{workflowId} now returns the participant role in the response.
Resolved Issues
| 4292343 | Improved signature clarity when using the TYPE signature option on mobile devices. |
| 4295123 | Fixed an issue that could prevent digital signatures from being visible when opening in a browser. |
| 4299289 | Improved the Replace Recipient experience by allowing the sender to include a message to the new recipient. |
| 4299857 | Fixed an issue that could cause a signed agreement to not apply the certificate seal. |
| 4304261 | Fixed an issue that could cause the Read Agreement option to not populate in the Options menu |
| 4308516 | Fixed an issue where users would continually be prompted to get admin consent when using OneDrive |
| 4310225 | Fixed an issue with agreements containing multiple signatures that would trigger a Server error : Error Message: The signature applied to this document is invalid. Please clear it and sign again. |
| 4310416 | Updated the v5 REST API to create users in an active state when created using POST /users |
| 4311287 | Fixed an issue where the Group navigation button would disappear on UMG enabled accounts after a users was removed from a group. |
| 4311956 | Fixed an issue where the designated font size for a field would not be reflected in the signer experience. |
| 4312302 | Fixed an issue that would remove the Reset Password option if the SAML mode was set to Mandatory. |
| 4312735 | Fixed an issue that would cause shared event notifications to be delivered when shared notifications were disabled. |
| 4313025 | Fixed an issue where a Form Filler role could not fill unassigned roles when Hybrid routing was enabled. |
| 4313030 | Fixed an issue where UMG enabled accounts would trigger an error using a custom workflow if the primary group of the sender is not allowed to send. |
| 4313264 | Updated the HIPAA enabled setting to permit access to the email link/image settings on the Global Setting page. |
| 4315839 | Corrected a problem with custom workflows that would not allow prefilling fields when the sender was also the second recipient. |
| 4316058 | Updated report field behavior to allow for leading zeros in text fields. |
| 4317382 | Corrected a problem with radio buttons showing the HTML code for apostrophes in the tool tip |
| 4317978 | Updated the way that File Attachments are ordered in the final PDF to group attachments based on the Page number of the field first, and the relative position of the field second (when reading left to right; top to bottom). |
| 4318598 | The GET/workflows/{workflowId} REST v6 API call now returns the participant role in the response. |
| 4318606 | The "Download Form Field Data" feature on the Manage page now returns field values for web forms that are not yet verified. |
| 4318617 | Fixed an issue where UMG enabled accounts would not allow a group admin to resend an invite. |
| 4318679 | Fixed an intermittent issue that could cause Written signature documents to fail to upload. |
| 4318926 | Corrected an issue that could trigger an error (The cookie functionality is disabled on your browser) when generating an agreement form a mobile device. |
| 4318991 | Fixed an issue that could cause the max login failure setting to be ignored if SAML was set to Allowed. |
| 4319068 | External recipients now are required to pass a second factor authentication process (instead of logging in to Adobe Sign) to gain access to completed agreements when multi-factor authentication is configured. |
| 4319422 | Fixed an issue where a recipient could be replaced without confirming the password (for password authenticated agreement) |
| 4319455 | Fixed an issue in advanced sharing where settings might not be persistent after saving. |
| 4320123 | Fixed an issue that could trigger an error when attempting to View and Approve an agreement on the Manage page. |
| 4320205 | Fixed an issue that could prevent saving progress when pre-filling an agreement using advanced sharing. |
| 4320542 | Fixed an issue for UMG enabled accounts where all of a user's group affiliations could be removed if one group was removed using Search. |
| 4321357 | Fixed an issue that could trigger an error on the send page when KBA is selected for authentication, and "Require name on Send" is enabled. |
| 4322445 | Improved authoring to ensure consistent background coloring. |
| 4322956 | Fixed an issue with custom email templates where the recipients would not see the actual email address of the signer. |
| 4323609 | In Development - Fixed an issue where agreements completed by uploading a signed document would not trigger the AGREEMENT_WORKFLOW_COMPLETED webhook notification. |
| 4323968 | Improved the signature locking feature to include Typed signatures when the name value is supplied via profile or API. |
Adobe Sign: October 2021
Improved Functionality
- Report Abuse Links - Small business and individual tier accounts now include a link for recipients to access a method to report potentially abusive activity regarding inbound agreement requests.
- 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 US 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.
- Send page updates - Customers with notary enabled can select the Requires notarization option on the recipient record, just to the right of the authentication method:
- Send page updates - Customers with notary enabled can select the Requires notarization option on the recipient record, just to the right of the authentication method:
Note:
Customers that use the embedded Send page in their applications or integrations will also have access to the notary functionality.
After the agreement is configured and the sender clicks Next, the sender is presented with additional configuration options for the notarization process:
- 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 |
|
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.
|
Parameter Name |
Type |
Default |
Required |
Description |
|---|---|---|---|---|
|
document |
Document |
|
optional |
A document that is associated with the agreement. |
|
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.
|
Parameter Name |
Type |
Default |
Required |
Description |
|---|---|---|---|---|
|
|
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 |
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.
|
Parameter Name |
Type |
Default |
Required |
Description |
|---|---|---|---|---|
|
notaryType |
Enum |
If only Notarize Notary on Demand Service is enable on the account, |
required |
NOTARIZE_NOTARY - Notarize Service provides the notary |
|
payment |
Enum |
BY_SENDER |
optional |
Only applies if type == NOTARIZE_NOTARY |
|
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>
|
|
||||||||||||||
The notary signer can follow the below sequence of API calls to complete the esign phase:
- GET /agreements/{agreementId}/members - to fetch the notary signer's participant ID & participant set ID
- POST /agreements/{agreementId}/members/participantSets/{participantSetId}/participants/{participantId}/signingTokens - to request signing token for notary signer with ACCEPT_BEFORE_NOTARIZATION capability
- POST /transientDocuments - to upload document that was reviewed
- 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.
Resolved Issues
| Issue | Description |
| 4308901 | Corrected an issue where delegating an agreement with phone authentication would prompt an error if the delegated phone number had the same country code. |
| 4314113 | Fixed an issue where default expiration dates could not be edited by users when sending a new agreement |
| 4318558 | Corrected an issue where replacing a recipient with phone authentication would prompt a "The participant set ID specified is invalid" error |
| 4319038 | Fixed an issue where the Sender was not getting the option for 'External recipients Identity verification' when sending using the 'Send in Bulk' workflow. |
| 4319798 | Fixed an issue that could cause the selection of a radio button to jump cursor focus to a different field. |
| 4320154 | Fixed an issue that could prevent a library template from saving to a new group relationship. |
| 4323013 | Fixed an issue where opening a web form on the manage page would trigger an error: "The document is not yet available or will have no pages to view." |
| 4323554 | Fixed an issue where the event time/date stamps for updating admin rights could produce two records with the same time values. |
| 4323609 | Fixed an issue where uploading a signed agreement in the manage page would not trigger the AGREEMENT_WORKFLOW_COMPLETED webhook. |
| 4325142 | Fixed an issue where custom email templates would not reflect the correct name value for a participant if they canceled the agreement. |
| 4326747 | Fixed an issue that could result in the Send in Bulk page not completing the load process, omitting the Upload and Send actions. |
| 4326855 | Fixed an issue that could prevent recipients from declining the approval of an agreement. |
| 4327000 | Corrected an issue that could cause Smart-Id credentials to fail, with the error indicating that no algorithms were found. |
