Last updated on
Jan 11, 2022 07:34:31 AM GMT
|
Also Applies to Adobe Acrobat Sign
Note:
This document highlights the new features, experience changes, and resolved issues in the current release.
Not all features/changes are guaranteed to be enabled on the date of the release.
If you would like to be notified of release notes via email, please subscribe here >
Improved Functionality
- Improvements to Manage Page Usability - The Manage page has been updated to improve "at a glance" data exposure:
Icons have been added to indicate when a Note or Reminder are attached to the transaction. Hover over the icon to get a quick view of important metadata associated with each agreement. Click on the icon to take action.
Advanced filtering has been added to the search feature to limit the returned data set by the searched object (e.g.: Notes)
- Improved Agreement URL Security - URLs sent via email and that point to agreements/PDFs now have a configurable lifetime that expires the link (Default is seven days). Recipients that attempt to access an expired link can request a new link to be emailed to them. This setting only applies to expiring the URL and does not impact the lifespan and viability of the agreement itself.
- Improved Agreement Sharing Security - Agreement sharing has additional controls to limit sharing to and from parties external to the account:
- Control the number of times that an agreement can be shared with an external party.
- Free tier: 2
- Trial tiers: 5
- Individual tier: 10
- Small business tier: 10
- Business tier: 20
- Enterprise tier: 20
- Control the ability of an external party to share the agreement.
- Control the number of times that an agreement can be shared with an external party.
More information on sharing individual agreements can be found here >
- New Trust Service Providers – SPID (Italy) and MitID (Denmark) 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.
Experience Changes
- The New Home and Manage Page Become the Standard Interface - Adobe Sign has retired the classic experiences for the Home and Manage pages, and all accounts have been transitioned to the modern experience.
The option to revert to the classic interface has been removed, and only the new user interface is to be supported going forward.
- Quick access action buttons on the Manage page have been updated - As part of the usability update to add the Notes and Reminder icons to the Manage page, the quick actions have been redesigned to have a similar look and feel.
- HIPAA Agreement Security - Accounts that have HIPAA settings enabled will treat all recipients of agreements as if they are unregistered users with no account affiliation. In practice, this means that recipients with a registered Adobe Sign user will not see these agreements on their Manage page.
- Users within the same account as the sender are the exception to the rule. All agreements sent to recipients in the same account are implicitly trusted, and the agreements are displayed on the Manage page, where they can be viewed and shared.
- Improved Contrast for the Signature Field - The blue font under the signature line is being darkened to comply with the Accessibility AA standard (4.5:1) for contrast.
Resolved Issues
| Issue |
Description |
|---|---|
| 4283949 | Summary: PDFs created with ADA compliant fields do not translate to ADA compliant fields when processed through Adobe Sign. |
| Fix: A new setting was introduced that preserves the Accessibility features of uploaded PDFs using a new tagging tree that includes a field appropriate type (e.g. span or link), a title derived from the field content, and an alternate text that matches the title. Tag strings are localized according to the agreement's locale. PDFs that do not have Accessibility features when uploaded will not be endowed with these features by the Adobe Sign process. | |
| 4295359/4323894 | Summary: Some characters from the Lithuanian and German alphabet (č, ė, and ß) were not properly handled by one of the dependent libraries, causing the characters to be omitted in the printed signature string. |
| Fix: The library was updated to properly handle the identified characters and render them appropriately in the signature string. | |
| 4304412 | Summary: A private CSC provider experience was not properly inactivating the Authorize button after the OAuth authorization popup was closed, allowing users to click Authorize again, and creating a "Loading" loop that would not terminate despite the signature being captured. |
| Fix: Updated the code to disable the Authorize action when the background screen becomes available and remains unavailable for a significant span of time while redirection takes place. | |
| 4308773 | Summary: Signing on the iOS mobile application could result in an "AUTO_CANCELLED_CONVERSION_PROBLEM" after the recipient signature was completed due to offline sync events that cause queued requests to be sent multiple times. |
| Fix: Server-side code has been added to evaluate if a successful conversion process has completed for the same participation ID when a conversion times out, allowing for graceful resolution of conflicts. |
|
| 4311477 | Summary: Completed documents do not present field information to screen readers in a usable way. |
| Fix: A new setting was introduced that preserves the Accessibility features of uploaded PDFs using a new tagging tree that includes field annotations that are converted to readable XObjects in final processing. | |
| 4316462 | Summary: Some agreements sent under the BioPharma settings were not being forced to reauthenticate when their authentication was managed by Active Directory Federation Service. This was dictated by how ADFS was configured, and if Forced Auth was configured to bypass the indication. |
| Fix: Code was added to require an ACR in combination with the ForceAuthn attribute, forcing the reauthentication process. | |
| 4317635 | Summary: Documents with multiple signature/initial fields would experience a screen-roll back to the previous field when clicking into a subsequent signature/initial field. |
| Fix: Code updated to properly resolve the focus of the next field after applying content to any given field. | |
| 4319974 | Summary: The Locale selector on the signing page was still visible when the signingurl is retrieved using GET /signingurl v6 REST API due to the API call falling back to the application value instead of the session value. |
| Fix: The API call has been updated to retrieve the setting value from the session (API user) instead of the application | |
| 4320942 | Summary: Agreements created with digital signatures and cloned fields could produce a signed document where the parent fields (of the cloned field array) could be editable. |
| Fix: Parent fields in cloned field arrays have been set to read-only. | |
| 4321067 | Summary: Accounts with a configured Display_Email value were seeing the email of the originator in agreement emails (instead of the Display Email value). |
| Fix: The userID is now compared between the participant userID and the current userID to return the Display_Email value for the account in outbound emails (when the value is set to something other than the default value). | |
| 4321335 | Summary: Some agreements would not permit CSC digital signatures when the agreement has been delegated multiple times. |
| Fix: Code has been added to the signature process to loop through the recipients and ensure that the signing phase is appropriate for delegated participation. | |
| 4322749/4329156 |
Summary: Transferred Web Forms do not trigger Webhooks for the new owner due to the ApiUserID failing to update. |
| Fix: The code around transferring web forms has been updated to ensure the UserID of the web form is updated when the object is transferred. | |
| 4323013 | Summary: Accounts with Limited document visibility enabled for web forms could trigger an error indicating "The document is not yet available" when creating a web form via API and then attempting to view it from the Manage page. |
| Fix: Code has been adjusted in a couple of settings involving web forms and limited document visibility to remove the conflict. | |
| 4323749 |
Summary: When modifying an agreement that has the sender as a signer that requires authentication, the system may not recognize the sender's session as being authenticated, prompting a server error. |
| Fix: Updated the Modify Agreement code to ensure the workflow checks the transaction properties to properly understand and enforce the sender's authentication requirements. | |
| 4324497 | Summary: Users in accounts with UMG enabled may not see all pre-existing shared library templates from a (non-primary) group they have been added to when building custom workflows. |
| Fix: The code involved with identifying all active groupIDs and their respective assets when building workflows has been improved. | |
| 4325294 |
Summary: Accounts that manage their users in the Adobe Admin Console were able to see the option to set a reminder on the Compose page when the default reminder was set by an admin. |
| Fix: The code has been updated to properly hide the reminder option when the default value is defined in the Admin UI. | |
| 4325826 |
Summary: Non-English languages did not properly filter returned data for Reports. |
| Fix: The code was updated to leverage the environment locale as the filtering parameter instead of using the static English parameter. |
|
| 4326335 |
Summary: Transaction consumption reports were including non-billable agreements |
| Fix: The reporting query was improved to filter out the non-billable transactions. | |
| 4326406 |
Summary: Authentication information was not persisting in reports for recipients in hybrid signing workflows. |
| Fix: The code behind the hybrid workflows has been updated to ensure that authentication information is captured and persisted so that reporting returns the correct values. | |
| 4326725 |
Summary: The number of recipients reported (via the Reports tab) can change to one less when the Sender is one of the recipients and is replaced in the transaction due to the code misrepresenting the replaced signer as a "Replacee". |
| Fix: The Replace signer code has been updated to properly identify replacing recipients as Signer roles. | |
| 4327494 |
Summary: Group-level admins can see the report data for users in the Default group when the "Only data from their own user group" setting is enabled. |
| Fix: The reporting code for generating the report CSV has been updated to properly capture only the data pertaining to the requesting admin. | |
| 4327780 |
Summary: The Events and Event Summary were not including unverified (but signed) web forms as completed (signed) agreements |
| Fix: The code that evaluates completed agreements has been updated to include signed and completed (but unverified) web forms. | |
| 4328045 |
Summary: When sending an agreement with the Sender as one of the recipients, and the Display Email setting set to a non-default value, the agreement can fail to send if the sender attempts to move back to the Compose page from the Authoring page. |
| Fix: The workflow that governs navigating back to the Compose page has been updated to properly manage the Sender when their email value is masked by the Display Email value. | |
| 4328110 |
Summary: A duplicate Signed and Filed email can be sent to the same recipient if they are included multiple times in the signature cycle. |
| Fix: The email distribution process has been improved to evaluate duplicate recipient email values and will only deliver one copy of the final email for any one transaction. | |
| 4328313 |
Summary: Adding a full HTML link to the Message field of an agreement could cause some email clients to convert that string into a clickable link. This functionality was not designed functionality, and subsequent code was added that prevented this effect, creating what appeared to be a bug in the agreement message field. |
| Fix: A setting has been added to properly render a hyperlink in the email message. This setting is not accessible to customers and must be edited by support or the account success manager. The setting is enabled by default on enterprise and business tiers of service. | |
| 4328950 |
Summary: New code added last June caused some users which were in the CREATED state to be converted to an invalid email address, but the global email address directory maintained the correct email address link to the user. This caused agreements sent to the user to be affiliated with a user type that would prevent the agreements from being listed on their Manage page. |
| Fix: Multiple code changes have been installed to prevent the issue from recurring, as well as to detect and warn about the conditions which can cause this type of problem. To include detecting the email address used for single-use pending users and automatically using the correct email address, preventing any new invalid users from being created when the other checks fail. |
|
| 4329688 |
Summary: Some document creation processes allowed for a file to be uploaded to Adobe Sign with multiple digital signature fields. These fields were rendered as blank fields on the final PDF. |
| Fix: An internal library has been updated to better annotate converted documents, ensuring only one digital signature field is applied and throwing the appropriate error when multiple fields are found (the expected behavior). | |
| 4329804 |
Summary: As part of a user cleanup process, users in a Pending status that were in an account with a claimed domain could have been converted to a Created status, resulting in the consumption of user licenses. |
| Fix: Users that were converted via the clean-up process have been returned to a Pending status. Code has been added to prevent Pending users in claimed domains from being converted to the Created status. | |
| 4331649 |
Summary: Signing a web form with only one name (one contiguous string) triggers a server error. |
| Fix: Error handling has been applied to web forms that will manage the use case and supply a proper error message as appropriate. |
Sign in to your account