Release 24.R6 - Production

Changed Behavior

Here are some of the changes in behavior that you might want to be aware of.

• Increased Color Contrast on Designer fields: Based on the feedback received in 24R5, we have introduced more vivid colors and a darkened border to help distinguish between recipients. We continue to remain compliant with WCAG 2.0 standards. For more information on our upcoming colors, contact our Support Team.  (refs PB-109894)

• Increased visibility of Recipient names in Signature Fields in the Designer: We have brought back Recipient names to Signature Fields, and increased the font size of those names. This will make it easier to identify who the signature belongs to. (refs PB-109609)

• RON and IPEN transactions are now stored indefinitely: Certain jurisdictions require that RON service providers preserve RON and IPEN transactions for a minimum of 10 years. To comply with these requirements, we now store all RON and IPEN transactions indefinitely, no matter what the data retention period specified in the transaction is. In addition, while it is possible to move a COMPLETED RON or IPEN transaction to the Trash bin, you cannot then manually delete it from there. While INCOMPLETED transactions can be deleted, note that the purging process will no longer automatically do this for either COMPLETED nor INCOMPLETED transactions. Should you require that a transaction be deleted, first verify if there are any local requirements for preserving transactions, videos, or journal entries and then contact our Support Team. (refs PB-105163)

• New Permission behavior when creating custom roles: With the introduction of the new transaction permissions Create New Transactions and Create Transactions from Templates Only, when creating custom roles via integration you must ensure that you include these new permissions. You can no longer depend on the existing Transaction permission to determine whether transactions are allowed to be created from scratch or from a template. (refs PB-10104)

• Changes to Signer and Sender phone number input: To conform with the industry standard of applying validation to all input fields, we have made the following changes to the Signer phone number input (via PUT and POST API calls) and to the Sender phone number input (under My Account > Personal Information): (refs PB-104448)

  • Input is restricted to a maximum length of 15 characters (previously up to 2000 characters were allowed)

  • Alphanumeric characters are allowed

  • The following special characters are allowed: + - # ( )

  This change will have no impact on existing phone numbers, unless you attempt to edit one of those numbers. In that case, these validations will be applied.

• New transaction cloning restrictions: Senders will no longer be allowed to clone transactions they do not have access to. In the rare situation that a sender was able to get access to the transaction ID of another sender this will prevent them from gaining access to documents they were not intended to see. (refs PB-108033)

Upcoming Changes

Here are some of the new features, changes and enhancements that we will be introducing in an upcoming release.

• For security reasons we will no longer allow Signers to use HTML code in the Reason field when declining a transaction. (refs PB-108289)

• Similarly, we will no longer allow Senders to enter HTML code in the Message to all recipients and Personal Message fields of a transaction. However, this can be enabled by contacting our Support Team. (refs PB-108287)

• When a Signer, who is also a Sender of the account, accesses an in-person signing session from an email invitation, they will do so as a signer and not as a host. This will happen even if the "Allow account senders to host in-person esigning transactions" feature is enabled for the account. The current behavior will remain unchanged when the Signer is the transaction owner. (refs PB-109998)

What's New

Here are some of the new features and enhancements we have made for this release.

Admins

• New transaction creation permissions: We have created two new transaction permissions; 1) Create New Transaction, and 2) Create Transaction from Templates Only. Existing users who already have transaction permissions will be given these new permissions by default. (refs PB-101047)

• A New App ID Verification Report is now available: You can now use the Reports menu to see ID Verification Reports. These reports allow you to monitor IDV related transactions, and review verification results. Also included are the pass and fail reasons for each verification. This report is available as part of the In-App Reports feature that must be enabled by contacting our Support Team. (refs PB-108738)

Integration Platform

• New workflow integrations: We have added new integrations to connect eSignatures to your favorite business applications. The following new integrations have been added (refs PB-105335):

  • OneSpan Sign for Guidewire ClaimCenter Cloud: The OneSpan Sign Accelerator for ClaimCenter integration provides a seamless integration between Guidewire ClaimCenter and OneSpan Sign, allowing ClaimCenter users to trigger electronic signature workflows from within ClaimCenter.

  • OneSpan Sign for Guidewire PolicyCenter Cloud: The OneSpan Sign Accelerator for PolicyCenter integration provides a seamless integration between Guidewire PolicyCenter and OneSpan Sign, allowing PolicyCenter users to trigger electronic signature workflows from within PolicyCenter.

Senders

• Senders can now view and edit the language associated to the 'Myself' and 'Group' type recipients: If limiting supported languages has been enabled, Senders can now select specific languages for the Myself and Group type recipients. For more information on the default behavior when this is feature is enabled, see Configuring Recipients. (refs PB-102392)

• BETA - Counter signing of a document is now available: You can now add a sender as a recipient to a transaction multiple times, so that counter-signing a document can be used. When counter signing, a sender first signs a document, waits for another recipient to sign, and then signs the document again, using an automatically enforced signing order. NOTE: This feature is currently in BETA and only available for Sandbox environments. Counter signing cannot currently be used with groups, external signers (signers who are not OneSpan Sign Senders), IPEN, Virtual Room, and RON transactions, or when the recipient type is set to “Myself”. It also cannot be used with templates. (refs PB-107338)

• BETA - Parallel and Sequential Recipient Order: You can now set a parallel and sequential order from the Sender UI when defining the recipients of a transactions. NOTE: This feature is currently in BETA and only available for Sandbox environments. (refs PB-107338)

Vaulting

• Enhanced eOriginal Audit Log: The eOriginal Audit log now contains an additional column that displays the IP address of the signer for the signing event. This IP address is taken from the Evidence Summary. (refs PB-109714)

Bug Fixes

The following issues were resolved in this release:

Notarization

• In some environments the highlighter feature in a Virtual Room transaction did not work properly. This would sometimes occur if a participant who did NOT have control at that moment activated the highlighter icon. This in turn would prevent the participant who DID have control from using the highlighter properly. (refs PB-104393)

Senders

• We have fixed an issue where blocking 3rd party cookies prevented the Designer from loading in an iFrame. (refs PB-108193)

• For consistency and ease-of-readability we have standardized the capitalization of the Permission strings in the UI, as well as for the Click-to-sign (Cliquer pour signer) and Click-to-initial (Cliquer pour parapher) signature fields in French. (refs PB-109355)

• When adding a new Recipient in the Designer, the Myself recipient would sometimes be inadvertently removed. This no longer happens. (refs PB-110388)

Signer Experience

• When attempting to sign a transaction that used checkboxes with conditional logic applied, one checkbox would sometimes deselect itself when selecting the second checkbox. (refs PB-108697)

• The Download and Archive buttons no longer disappear when using a very long transaction name. Now, the transaction name is truncated, to allow all actions to appear. (refs PB-108697)