In this release, we have made UI improvement by moving the Terms and Conditions, Privacy and Api links to the "About" dialog. This change helps streamline the interface, ensuring essential information remains accessible while maintaining a cleaner and more organized design.

All supported storage types now include the capability for backing up envelope data. To enable a specific <storage> type for backups, ensure that the <usedFor> setting in the _gobal.xml configuration file is updated. This setting must include either "Backups" or "Everything".

The generated backup will be divided into multiple parts, allowing each part to be downloaded and extracted separately. The size of each uncompressed part can be customized by setting the uncompressedBackupPartSizeinMB parameter in the _global.xml under the path .../jobs/BackupJob/uncompressedBackupPartSizeinMB. By default this value is set to 1000 MB.

For more information about the backup feature please see Organization Settings#Backup

For detailed information about the configuration in the global.xml please see /wiki/spaces/eSign/pages/91883022 - restricted access

The AML identification is now fully supported. All disposable document data fields

• Document Type
• Document Number
• Document Issued On
• Document Issued By
• Document Expiry Date and Document Issuing Country

are optional. However, if any one of the document fields is provided, then all of them must be completed, with the exception of Document Issued By, which remains optional in all cases.

For more information about disposable certificate in general please see Electronic Signature Guide#Disposablecertificate, Recipients Page and Signer Guide#Disposablecertificate

We are excited to introduce a new feature that streamlines the process of certificate issuance. Instead of manually providing data for disposable certificate issuance for each envelope, you can now leverage an eID assertion from an authorized eID service provider via OAuth authentication. This enhancement simplifies the workflow by using a single assertion across multiple envelopes.

Additionally, we have added a toggle option in the Identity Providers section, available when adding a new OAuth or editing an existing one. This toggle allows you to easily enable or disable the use of eID assertions for OAuth, giving you greater control over how eID assertions are managed within your system.

For more information please see the Identity Providers

You can now create custom batch groups, allowing you to specify which signatures should be grouped together and which should be in separate groups. Previously, it was only possible to define a single batch. With batch groups, a signer can sing multiple signature fields simultaneously within a defined group. This feature is available for both the UI and the API, giving you greater flexibility and control over the signing process.

For more information about the UI and multiple signature batches please see the User Guide#Batch-Signature and Signer Guide#BatchSignature.

For more information about the Api and multiple signature batches please see Envelope structure#TaskConfiguration

We are excited to introduce a new feature in the extended signing options section under Organization Settings: "Prevent actions on signed PDFs". This per-organization setting allows administrators to prevent any actions on already signed PDFs, addressing scenarios where signed documents should remain unaltered.

Key points:

• Per-Organization Setting: This feature can be enabled or disabled for each organization, providing flexibility based on specific needs.
• Protection for Signed Documents: Ensures that once a PDF is signed, no further actions can be taken, preserving it integrity.
• No impact on existing Envelopes: This setting does not affect envelopes that have already been sent.
• Global XML Configuration: The setting is also configurable via the global.XML for streamlined, centralized management.

This enhancement ensures greater control and security over your signed documents, maintaining their authenticity and integrity.

We are excited to announce the addition of a new feature: Instance-Wide OAuth Provider MyNamirial. This enhancement allows administrators to configure a single OAuth provider for the entire instance, simplifying the authentication process for all users.

Key benefits:

• Unified Authentication: Streamline login procedures by using a single OAuth provider across the instance.
• Improved Security: Centralize authentication management to enhance security and compliance.
• Easier Management: Simplify the configuration and maintenance of user authentication settings.

Introducing enhanced notification management with this release.

We have revamped our notification handling system to provide even more flexibility. Now, alongside emails, users can opt for phone number-based notification, expanding accessibility.

Within the organization settings, you now have the option to choose between email or SMS for notifications. Additionally, you can customize the templates for SMS notifications in the notification templates section.

For more information please see the Organization Settings and Notification Template Settings.

Please also see the /wiki/spaces/eSign/pages/91992775. We added two new feature flags in order to use the new notification channel: AllowSmsNotification and BulkEnvelopesWithSmsNotification

We have overhauled our notification queue processing capabilities, enhancing efficiency and performance. Now, notification are managed with greater agility, ensuring timely delivery and smoother operations.

We have introduced a new feature to prevent users and (admin-web admins) from updating or changing their password to a previously used one. The system now tracks a specified number of old passwords, which can be configured in the "passwordValidationRules" node under the "numberOfIldPasswordsWhichShouldNotBeMatched" setting in the globalXML.

This check applies to the following pages:

• Reset Password
• Reset/Change the automatically generated password

Additionally. the new configuration offers the following values:

• Default: 8
• Maximum: 20
• Minimum: 0

Setting the value to 0 means that the system will not check for any old passwords, allowing users to reuse passwords they have used before. It is important to note that in the case of resetting or changing the automatically generated password, the system will always prevent the reuse of the same generated password.

With the this release we have changed the list of supported types for the document conversion service. In detail the following types are no longer supported:

• "ods",
• "odp" or
• "odt" filetpyes.

Following types are allowed:

• .pdf
• .docx
• .xlsx
• .pptx
• .png
• .bmp
• .jpeg
• .jpg
• .doc
• .xls
• .ppt
• .gif
• .jp2
• .tif
• .txt
• .xml
• .md

To enhance user experience. we have refined the tooltips below to provide clearer explanations of each setting's functionality:

For the definition/index page:

• Recipient role
  • Needs to sing
  • Receives a copy
  • Must view
  • Needs to sign (P7M)
• Recipient settings
• Authentication settings
• Signature settings
• Remove recipient

New document types:

• Residence Permit
• Italian National Electronic Identity Card (CIE)
• Temporary Residence Permit
• Documents for Embassy/Consulate Personnel

New identification types:

• Residence Permit
• Temporary Residence Permit
• Embassy/Consulate Personnel Document

For more information about the disposable certificate please see: Designer Page#DisposableCertificate, Electronic Signature Guide#Disposablecertificate and for an API use case: Envelope structure#DisposableCertificate

The FilebasedLocalCertificateGSP is a GenericSigningPlugin which allows applying a signature by using a local certificate, which is held by the signer and is available as files (.cer, .key):

With our latest update, users now have the flexibility to select a custom sealing certificate for individual envelopes. This enhancement extends beyond the previous organizational-level limitation, empowering users with greater control over the sealing process for each specific envelope. This means you can tailor the security measures to suit the unique needs of each document ensuring an even higher level of protection and customization.

This setting can be found on the Recipients Page in the section Envelope Settings. Please note that this feature is also available via API.

For more information please see: Custom Sealing Certificate

With this release we have added the general policies for the viewer that dictate the actions and content accessible to the user on the Main Application Screen - SignAnyWhere Viewer (for the UI as well as for API v6). The following policies have been added:

• Allow to save the document
• Allow to save the audit trail
• Allow to print the document
• Allow to attach ad hoc pdf to the document
• Allow to reject the document
• Allow to undo the last step

We are excited to introduce the "DigitalRemoteSignature" feature flag with this latest release. Therefore, we have added a layer of flexibility, allowing more selective activation of this feature to maintain a cleaner user interface. Additionally, for on premise, the configuration is now available on a per-organization basis, enabling the choice to enable or disable the Digital Remote Signature method.

By incorporating this feature flag, we empower organizations to fine-tune their signing preferences according to their specific requirements, ensuring a more personalized and streamlined experience.

Please also see: /wiki/spaces/eSign/pages/91992775

Introducing the latest feature: "Activity-Engine Custom Localizations" within the organization settings. This setting allows you to override localizations, enabling customization for various elements such as signature image rendering labels and text for transaction code configuration (e.g. SMS text). You now have the ability to upload a translation bundle, reset to default settings, download the current translation bundle, and also access the default template for localizations. This feature empowers users to tailor their interface and messaging precisely to their preferences, ensuring a seamless and personalized experience.

Get ready for a visual transformation as we introduce a captivating new color scheme that revolves around the enchanting primary color, teal. This change marks a departure from the previous purple theme and brings a fresh, invigorating look to our platform. The advantages of this recoloring are not just cosmetic, it enhances user experience, making your interactions more engaging and visually appealing.

Please also see: UI/UX Rework - New Color Scheme 2023

• User Event History Access: With this permission, users can delve into the event history of an envelope, gaining valuable insights and control over the process.
• Anonymized Organization Envelope History: This permission empowers users to access anonymized history data for any envelope within their organization, ensuring that you have the data you need while maintaining privacy and security.

You can find both permissions in the "Roles and Permissions" section.

Please note that this feature is also available via api with the following call:
GET /v6/envelope/{envelopeId}/history

Please also see: Envelope History

We are pleased to announce the introduction of a new feature flag, "TypeToSignSignature", with this release. This feature flag brings forth notable implications for both existing and new organizations. Existing organizations as well as new organizations will have access to the TypeToSign signing method. However, we now offer the added flexibility of being more selective in activating this product feature to keep the UI a bit more clean. Furthermore, on-premise customers can configure on a per-organization basis if they want to allow TypeToSign signing method.

By implementing this feature flag, we empower organizations to tailor their signing preferences to their specific needs, ensuring a more customized and efficient experience.

For further details, please refer to /wiki/spaces/eSign/pages/91992775.

We are pleased to introduce a new feature flag to allow an organization specific timestamp - "AllowUsingCustomTimestampService". This feature allows you to set a dedicated timestamp service for each organization. With "AllowUsingCustomTimestampService", you gain the ability to fine-tune timestamp configurations on a per-organization basis. This means that it is now possible to customize timestamp services to meet the specific needs of each organization in your instance, ensuring that timestamps align perfectly with their unique requirements. This feature provides enhanced control and flexibility, making timestamp management more precise and adaptable across your entire instance.

Please also see /wiki/spaces/eSign/pages/91992775 and the Organization Settings

We are excited to introduce new configuration options for OAuth in this release. You now have the flexibility to control how OAuth values are compared, whether it's case sensitive or not. Specifically, for the Signer OAuth Provider, the following comparison modes are additionally available:

• Validate (respect case): OAuth values will be validated with strict case sensitivity.
• Validate (ignore case): OAuth values will be validated while ignoring case differences.

This enhancements offer greater control and customization, ensuring your OAuth integration is tailored to your exact needs.

For general information about OAuth please refer to OAuth2 Authentication Reference and for samples OAuth2 Authentication Samples.

We are pleased to announce the introduction of a new feature flag, "DrawToSignSignature", with this release. This feature flag brings forth notable implications for both existing and new organizations. Existing organizations as well as new organizations will have access to the DrawToSign signing method. However, we now offer the added flexibility of being more selective in activating this product feature to keep the UI a bit more clean. Furthermore, on-premise customers can configure on a per-organization basis if they want to allow DrawToSign signing method.

By implementing this feature flag, we empower organizations to tailor their signing preferences to their specific needs, ensuring a more customized and efficient experience.

For further details, please refer to /wiki/spaces/eSign/pages/91992775.

We are pleased to announce the introduction of a new feature flag, "Backup", with this release. This feature flag brings forth notable implications for both existing and new organizations. Existing organizations as well as new organizations will have access to the Backup feature. We believe in giving our users the ultimate control and flexibility in managing their document workflows. With this feature flag, you now have the power to enable or disable the "Backup" envelopes functionality based on your specific needs and preferences. In addition to its control benefits, this flexibility also contributes maintaining a clean and streamlined user interface. Furthermore, on-premise customers can configure on a per-organization basis if they want to allow "Backup".

For further details, please refer to /wiki/spaces/eSign/pages/91992775 and Organization Settings#Backup.

We are excited to announce some significant improvements to our notification settings that will elevate your experience with our platform. To provide more clarity and organization, we have moved relevant notification settings into a dedicated <notificationSettings> node, ensuring easier access and management.

Here are the key changes you need to be aware of:

1. Move Notification relevant settings
   1. We have streamlined the location of notification settings for a smoother user experience. They can now be found within the <notificationSettings> node, making it more intuitive to customize your preferences.

2. Renaming <mailAttachmentDonwloadsExpireDays> to <attachmentDownloadsExpireinDays>

   1. To enhance consistency and understanding, we have renamed this settings. Please note that the functionality remains the same, we simply improved the naming for better clarity.
3. Change from single <emailNotificationSetting> to a list of <notificationPlugins>
   1. We are excited to introduce a powerful change that will allow you to configure multiple <notificationPlugin> instances rather than just a single one. This enhancement empowers you to have more granular control over your notification services.

For each node in the <notificationPlugins> list please take note of the following:

1. CUSTOM_PLUGIN_ID must be set and needs to be unique on the instance

2. Exactly one plugin must be marked as default (<notificationPlugin customPluginId="CUSTOM_PLUGIN_ID isDefault="1">)

3. Mail providers which previously called <FLOW_WEB_URL>/WebHook/Email to report status updates (bouncing), now need to call  <FLOW_WEB_URL>/WebHook/Email/CUSTOM_PLUGIN_ID with the same payload as before
4. Custom plugin implementations need to be adapted to follow the new format (nuget Namirial.Plugin.Notification 23.30.0.4)

Configuration changes can be found here:

• /wiki/spaces/eSign/pages/91953145 (restricted access)
• /wiki/spaces/eSign/pages/91951314 (restricted access)
• Organization Settings#NotificationPlugin

We are pleased to announce the introduction of a new feature flag, "ClickToSign", with this release. This feature flag brings forth notable implications for both existing and new organizations. Existing organizations as well as new organizations will have access to the ClickToSign signing method. However, we now offer the added flexibility of being more selective in activating this product feature to keep the UI a bit more clean. Furthermore, on-premise customers can configure on a per-organization basis if they want to allow ClickToSign as signing method.

By implementing this feature flag, we empower organizations to tailor their signing preferences to their specific needs, ensuring a more customized and efficient experience.

For further details, please refer to /wiki/spaces/eSign/pages/91992775.

Introducing SPID Integration in eSignAnyWhere!
We are thrilled to announce the upcoming feature release of SPID integration into eSignAnyWhere, which will greatly enhance the signing process. SPID (Sistema Pubblico di Identità Digitale or Public Digital Identity System) will now be available as an OAuth Ident Provider, allowing seamless and secure authentication.

Key features of SPID integration:

1. Signer OAuth Ident - With SPID integration, users can now enable SPID as their OAuth Ident for a streamlined and efficient signing process.
2. Enhanced Security - SPID will serve as the OAuth Ident provider, ensuring robust security measures during the authentication process.
3. Recipients who opt for SPID will have this Public Digital Identity System configured as their method of authentication.

Moreover, the system administrator can now define, for specific identification providers such as SPID, to overrule the configuration of the Local Registration Authority (LRA) for issuing Namirial Disposable Certificates.

Further information can be found here: SPID Identification via OIDC and /wiki/spaces/eSign/pages/91884678

Prepare to elevate your e-signing process with the SPID integration in eSignAnyWhere. Stay tuned for this exciting release, as we continue to prioritize security, efficiency, and user satisfaction.

We are pleased to announce the introduction of a new feature flag, "SmsOtpAuthentication", with this release. This feature flag brings forth notable implications for both existing and new organizations. Existing organizations will continue to have access to SMS authentication. However, we now offer the added flexibility of being more selective in activating this product feature to keep the UI a bit more clean and to avoid the risk of "hidden sms costs" with some packages. Furthermore, on-premise customers can configure on a per-organization basis if they want to allow SMS sending for authentication purpose.

For new organizations, the following outcomes arise:

1. Trial (Free) and Personal Packages:
   1. SMS authentication will not be available for all new organizations opting for these packages.
2. Professional and Business Packages:
   1. New organizations subscribing to the Professional and Business packages will have access to SMS authentication.

By implementing this feature flag, we empower organizations to tailor their authentication preferences to their specific needs, ensuring a more customized and efficient experience.

For further details, please refer to /wiki/spaces/eSign/pages/91992775 and /wiki/spaces/eSign/pages/91882773 (restricted access).

Introducing Preemptive Basic Authentication and flexible timestamp validation options:

• We are thrilled to announce the addition of preemptive basic authentication to our HTTP-based communication protocols.
  • With the preemptive basic authentication, it is possible to proactively send the authentication credentials without waiting for a server challenge. Can be configured in Server Core global configuration.
• Introducing flexible validation options for timestamp URIs
  
  • The addition of the new configuration section enables seamless switching of validation implementations for specific timestamp URIs. This utilizes regular expressions to provide granular control over the validation process. We recognize the importance of security and integrity when handling timestamp URIs, and this enhancement aligns perfectly with our commitment to delivering robust security solutions. By allowing easy customization of the validation implementation, Server Core equips administrators with a powerful tool to adapt and evolve their systems according to changing requirements and best practices. Can be configured in Server Core global configuration.

Introducing enhanced flexibility empowering timestamp customization:

• We are pleased to announce a powerful new feature in Server Core's global configuration. The addition of a dedicated configuration section that allows effortless disabling of the "Nonce" parameter validation for specific timestamp URIs. This functionality, driven by regular expressions, empowers administrators with greater control over their validation processes. We understand that security and customization are paramount in today's evolving landscape. By incorporating this feature, Server Core demonstrates its commitment to empowering administrators with tools to meet their security and compliance needs effectively.

These features support the seriousness in our strategy to enter new markets - including Latin America and Switzerland - through increased flexibility of integration options.

The file storage system has been reworked to allow separate storage for backups. This enables more efficient and organized data management. Amazon S3 support: We have integrated support for Amazon S3 as a file storage option. Users can now leverage the power and scalability of Amazon S3 for their storage needs.

Configuration changes:

• The configuration location for the temporary folder has been modified. The previous "storage\tempfolder" configuration must be replaced with the new "tempFolderPath" instead.
• Update storage node requirements: Each storage node in the configuration now requires two attributes. Firstly, a mandatory unique "id" attribute with a maximum length of 36 characters. Secondly, a mandatory "type" attribute with available options being "FileSystem" or "AmazonS3".

• Usage definition for storage nodes: To specify the purpose of each storage node, a "<usedFor>" node has been introduced. Users can choose from three options: Files, Backups or Everything.
• Amazon S3 limitation: Please note that Amazon S3 can only be used as a storage option for the "Files" category.
  • AmazonS3 is currently only valid for Files option.

For more information and samples please refer to the documentation provided in the /wiki/spaces/eSign/pages/91883022

The default redirect after sending an envelope is now the Envelope Details page (Document details). The redirect can be changed in the Admin Web to the following:

• Show document details (default) - Document details
• Show document overview - Documents (Envelope Filter Views)
• Show home dashboard - Home (Dashboard)

Please also see /wiki/spaces/eSign/pages/91969614.

Improved the handling of the generic signing plugin. For general information about the generic signing plugin please see /wiki/spaces/eSign/pages/91883858

It is possible to change the UI language via a route parameter e.g. https://demo.esignanywhere.net/en/Home/Index to view the UI in English language https://demo.esignanywhere.net/it/Home/Index to view it in Italian. This applies also for the agent drafts which can be opened with a defined language now e.g.: .../es/AgentRedirect/Index?draftId=##id## to view the UI in Spanish. Please see the supported languages here: Language Support

The language parameter is optional, if not set then the language will be set to the UI language setting from the authorized user.

Default signature type can now be set for drafts as well as for templates. Following signature types are supported:

• ClickToSign
• DrawToSign
• TypeToSign
• Digital Remote Signature
• Biometric Signature
• Local Certificate
• Disposable Certificate
• SMS-OTP Signature

For more information how to set the default signature type in API see Using Templates for Standard Processes and Using drafts to prepare envelopes.

Also available via UI in the Organization Settings → Default Signature Settings, on the create envelope page in the advanced settings as well as on the edit template page in the advanced settings.

In the organization settings you can now find a new configuration to show a warning dialog if there are fewer signature fields than signers. If this settings is enabled (default) the warning dialog will be shown if:

• only some of the signers have no signature
• when all of them have no signature

Please see the Organization Settings.

Furthermore, the import and export of an organization includes now also a node for this setting. Information can be found here: /wiki/spaces/eSign/pages/91882770 (restricted access)

The zip file which can be downloaded from the envelope details page is now named to the envelopeId (only if the envelope contains more than one document). This applies also for all Emails to CC where it is possible to download the documents. Please see the following email templates which are affected:

• Send copy of finished envelope to CC recipient
• Send copy of finished envelope to CC recipient (non-registered)
• Send signer list to CC recipient
• Send signer list to CC recipient (non-registered)

For more information about email templates please see Notification Template Settings

In addition to various bug fixes, this version also addresses several moderately severe security issues.

Document retention can be enforced for an organization via the Admin Web. If the limit is changed (in the Admin Web) to a value which is more restrictive than the setting in the organization, the organization is reconfigured to match this new limit.

For detailed information see /wiki/spaces/eSign/pages/91882773

SOAP has been removed in this release as already announced in the eSignAnyWhere version 20.28 and 20.42. See Migration Guide - SOAP to REST

REST API v1 and v2 were announced as deprecated (Migrate REST API clients from v1, v2, v3 to v4) and are now being removed in this release.

With this setting it is possible to define a specific order for the tasks. In addition to order the tasks by drag and drop it is also possible to define a sequence mode:

• No sequence enforced - allow form filling in any order
• Sequence required tasks
• Sequence enforced - enforce sequence for all tasks

With the link form field it is possible to add hyperlinks to the document. This allows the recipient to just click on the link to navigate to linked pages.

Read confirmation (if one of the following is selected as required the recipient then must confirm that he/she has read the area, page or the document. You can choose between the following:

• Read confirmation (Area)
• Read confirmation (Page)
• Read confirmation (Document)

It is now possible to add a validation for the textbox. You can choose between the following validations:

• None
• Date
  • Format
  • Minimum value
  • Maximum value
• Email
• Number
  • Decimal Places
  • Symbol
  • Symbol location
  • Group Separator
  • Decimal Separator
  • Minimum value
  • Maximum value
• Phone
  • Phone type
    • international
    • international leading zeros
    • international leading plus
• Time
  • Format
  • Minimum value
  • Maximum value

By enabling the "Custom Signature Image" checkbox, the sender can allow (or enforce) that the signer is uploading an additional image to be shown in the signature field. Such custom signature images can be used to ask for placing a company stamp picture, or to insert Hanko stamps. See Story: Using external signature images for additional use case details. Note that the global setting here sets and overrules the signature-type specific settings, as this property can also be defined on a per-signature-type level in the Advanced tab.

Additionally to the general settings you can define the following in the advanced settings for attachment fields:

• Attachment icon
• Either enable or disable to set a custom file name and if enabled enter a file name

Additionally to font size and text color you can also choose between italic and bold. This option is available for the following fields:

The same settings (elementId and FieldDefinition) can also be set for the following predefined fields:

• EmailFields
• InitialsFields
• GivenNameFields
• SurnameFields
• FullNameFields
• DateFields
• Static Text

The middle name can now be added for the initials.

Additionally to the text field it is also possible to add a predefined static text to the document.

Please note the following: It is possible to add a static text although the document was already signed. This is the main difference between the textfield and the static text as a predefined element.

For the radio button following additional setting can be set:

• Select in Unison

Beside the language, email settings and the personal message you can now also add the following:

• Language
• Email settings
• Personal message
• Activity settings

You can now find the recipient finish actions on the create envelope page in the recipients section:

You can now find the recipient finish actions on the create envelope page in the recipients section:

Disposable certificate advanced settings now also contains the option to select a long lived certificate. You can also force this setting in the organization settings.

On a signature field which allows recording a biometric signature, the biometric verification can be enabled in case the (optional) SIGNificant Biometric Server was also installed and properly configured.

When enabling the biometric verification, the sender has to provide the signer's user ID which was used to enroll a profile.

The sender can configure behavior of the biometric verification:

• It is possible to allow to skip the verification (in case the matching score is below the required threshold).
• The signature field can be configured to allow enrolling signatures to a profile if there have not been enough signatures enrolled to the profile yet.

Another option allows the sender to define that only the validation response (which includes the validation score obtained from biometric server) should be stored in the signed PDF, instead of storing the entire biometric data. In this case, the document itself does not store the data required for a forensic examination of the handwritten signature, but legal considerations may result in preferring that option, in some countries.

For a local certificate signature, the sender can define filters on certificates to be offered for signing. Currently it is possible to define a preferred signature algorithm. Certificates using this algorithm will be ranked higher in the certificates offered to the signer.

The sender can also enforce to use the selected (preferred) one, which avoids that the signer is using certificates based on another (probably weaker) digital signature algorithm. You can enable preferred hash algorithm and enforce the use of the chosen algorithm. The enforce shown algorithm will be dynamically changed if the preferred algorithm is changed.

Options available for all signature types

In the section "Display following stamp imprint data", the sender can define which data to be contained on the signature representation on the PDF. Note that some items will be ignored when defining a custom stamp imprint configuration that simply does not contain a specific field for all or some signature types.

The following default values are used for all signature types:

• Signature rendering
  • custom signature image: false
• Stamp imprint settings
  • Extra information: true
  • Email address: true
    The signer's mail address, automatically filled with the information available on the activity.
  • Transaction Id: true
  • Transaction token: true 
  • Phone number
    Automatically filled with the information available on the activity, when applicable. Always printed in the international format with country prefix (e.g. +39 or +43)
  • IP address: true
  • Name: true
    the full name (given name and family name) of the signer, automatically filled with the information available on the activity.
  • Signature date: true
  • Font name: Configured organization default is used
  • Font size: Configured organization default is used
• Exceptions for Draw2Sign:
  • "Extra Information", "Display Email Address", "Display IP Address", "Display Name", "Display Signed on Date" is used from the organization default settings (configurable in the Organization dialog under "Extended settings for 'Draw to sign')

A-Trust signature type can now be configured in the UI.

Note: For the A-Trust signature configuration you need an A-Trust Signaturbox first. For more information please contact us.

Further information: A-Trust Guide (restricted access)

BankId signature type can now be configured in the UI.

For more information please see: /wiki/spaces/eSign/pages/91977870 (restricted access)

The BankID implementation we are talking about here is the Swedish BankID implementation. The BankID is a common identification method provided by a consortium of the Swedish banking sector, and the identities (which are bound to the national unique number of a citizen) are linked to confirmed identities based on Anti-Money-Laundry verifications. For that purpose, a local device (Mobile Device with BankID App, or Desktop PC with installed BankID Desktop application) has to be installed. The app or application on the local device has to be linked uniquely to the confirmed identity. In addition, the service offers a signing method to sign with a signer-individual certificate provided by the Swedish BankID consortium.

It can be used both as authentication method (when opening a workstep / signer activity), and as signature type on a signature field level.

It is now possible to choose between the following validity times for disposable certificate:

• Regular disposable
• Lean disposable with validity of 60 min
• Lean disposable with validity of 30 days

It is possible to either change the validity in the web UI:

or it can be changed in the _global.xml (for more information please have a look at the RemoteSignaturePlugin - restricted access).

<!-- Defines the type for disposable certificate (Overridden by customization service) -->
<DisposableType values="Disposable;LeanDisposable;LeanDisposableExtendedValidity">Disposable</DisposableType>

A complexity check is now available for the signature type Draw2Sign. Please see the following sample configuration (customization.zip) for a complexity check:

 <signaturecomplexitychecks>
      <draw2sign>
        <minimumpackets>
          <!--Minimum count/amount of packets for a signature. Default is empty value or 0 => All signatures are accepted in terms of length-->
          <variable name="SignatureComplexity_Draw2Sign_MinimumPackets" value="0" comment="Minimum count/amount of packets for a signature. Default is empty value or 0 => All signatures are accepted in terms of length" category="global/ViewerPreferences/SignatureComplexityChecks/Draw2Sign/MinimumPackets" />
        </minimumpackets>
        <minimumtimeinms>
          <!--Minimum time in milliseconds for a signature. Default is empty value or 0 => All signatures are accepted in terms of duration-->
          <variable name="SignatureComplexity_Draw2Sign_MinimumTimeInMs" value="0" comment="Minimum time in milliseconds for a signature. Default is empty value or 0 => All signatures are accepted in terms of duration" category="global/ViewerPreferences/SignatureComplexityChecks/Draw2Sign/MinimumTimeInMs" />
        </minimumtimeinms>
      </draw2sign>
    </signaturecomplexitychecks>

Please note that in the given configuration all signatures are allowed without checking time and packets.

• It is now allowed to have multiple identity providers in use for a single recipient. Please note that this is only allowed if the providers have a completely identical set of update rules.
• Nested JSON in JWT are now also accepted by the OAuth2 checks.
• The separation is now more visible between the OAuth2 Authorization Providers and the OAuth2 Identity Providers. In detail:
  • In the OAuth2 Authorization Providers list you will now only find OAuth2 providers with just validation rules
  • In the OAuth2 Identity Providers list you will now only find OAuth2 providers with at least one update rule
• Stabilization of OAuth2
  
  • Stabilization of the OAuth2 provider authentication via api.
  • The template which was created from an envelope with OAuth2 configuration now also includes the OAuth2 configuration from the original envelope.

For more information about the OAuth2 configuration please have a look at the OAuth2 guide and for samples please also see the OAuth2 sample guide.

• Additionally to the hash of the finished envelope you can now also find the hash of the initial document in the audit trail
• The audit trail now also contains the eSAW version information
• The audit trail sealing now considers PAdES signature level.
• Stabilization of the audit trail
  • You can now find information about the OAuth2 authentication in the audit trail.
  • Timezone formatting issue fixed.
  • Chinese characters are now supported to be displayed correctly in the audit trail.

For more information about the audit trail please see the electronic signature guide.

There will no longer appear exceptions if a document is uploaded with predefined syntax which do not meet the requirements. Instead you will get the following warning:

You can either proceed with the uploaded document or cancel the upload.

For more information about the field markup handling in general please see the following guide: Field markup

You can now also configure JWT for the OAuth2 authentication for user authentication and signer authentication. For more information please see the How to configure OAuth2 authentication. For OAuth2 samples please see this guide. In this guide is also a ID Austria sample with JWT documented.

Document browsing is now also supported for the devices listed above. Please note that the feature is disabled per default but can be configured either in the SAW viewer global.xml or in the customization service.

global.xml:

 <!-- Defines whether or not to enable document view on some specific compatible signature pads (e.g Wacom STU 520/530/540, NT5010 or some StepOver devices)
           'useDocViewMonitor': defines whether or not to use a 'doc view monitor' upon using specific compatible devices (e.g. Wacom STU 520/530/540, NT5010) -->
      <DocViewModeEnabled useDocViewMonitor="1">0</DocViewModeEnabled>

Customization Service:

  <!--Defines whether or not to enable document view on some specific compatible signature pads (e.g Wacom STU 520/530/540, NT5010 or some StepOver devices)-->

   <variable category="global/SignificantDriverConfiguration" comment="Defines whether or not to enable document view on some specific compatible signature pads (e.g Wacom STU 520/530/540, NT5010 or some StepOver devices)" value="0" name="DocViewModeEnabled"/>

   <!--For 'DocViewModeEnabled': defines whether or not to use a 'doc view monitor' upon using specific compatible devices (e.g. Wacom STU 520/530/540, NT5010)-->

   <variable category="global/SignificantDriverConfiguration" comment="For 'DocViewModeEnabled': defines whether or not to use a 'doc view monitor' upon using specific compatible devices (e.g. Wacom STU 520/530/540, NT5010)" value="1" name="UseDocViewMonitor"/>

</significantdriverconfiguration>

This feature allows signers to upload their picture (custom signature picture) and add it as additional graphics to the stamp imprint. Furthermore signers can store the signature image within a gallery for later usage. For more information please see the following documentation: Use external signature image

All dialogs support now keyboard usability.

"ESC" keypress

• closes the dialog
• stops additional tasks if required

"Enter" keypress

• activates the primary button, when no other action is required in the dialog
  • e.g. "Finish" dialog

"Tab" keypress

• to navigate to the next element

For more information about the keyboard usability and about other aspects of the accessibility please see this guide.

The generic signing plugin is now also available for short time certificates (one time, one shot,  disposable etc.).

For more information about the generic signing plugin please see the release notes 21.16. For detailed information about the REST configuration of the generic signing plugin please see this guide.

With eSAW 21.31 we introduced, as part of a bugfix, a more strict phone number validation. For example: SMS-OTP authentication, the phone number must be provided in international format (+xxyyyyyyyyyyy) where +xx is the country prefix, and yyyy is the phone number inclusive carrier prefix (different length of country prefix and phone number are supported). The  use of phone numbers without country prefix - which did not return an error via REST Api, but did not lead to successful delivery in many cases - cannot be supported any longer as it was not determined which country is used.

We improved again the performance of our solution to provide you an excellent user experience.

The identity settings providers moved to a separate configuration page. Those settings can now be found in Settings → Identity Providers. Please also see the next figure:

The SwissCom OnDemand Certificate is now also available in the UI. You can find the settings for the SwissCom OnDemand Certificate in Settings → Organization.

The settings for the recipient can be found on the create envelope page. There you have to fill in the mobile phone number, the country of residence and the organization (optional).

After these configurations you can use the SwissCom OnDemand Certificate as signature field in the UI:

Moreover, you can create a SwissCom OnDemand certificate signature field with Advanced Document Tags.

Just add the following code to your document to place a SwissCom OnDemand certificate signature:

[[!sigField1:signer1:signature(sigType="SwissComOnDemandCertificate"):label("some label"):size(width=150,height=60)]]

For general information about the advanced document tags please see: Use Advanced Document Tags to insert Form Elements or Signature Fields

The recipient who has to view the document was renamed to "Must view" recipient instead of "Acknowledge" recipient. For example:

The feature implementation change of envelope expiry allows to specify absolute expiration timestamps (date and time), beside relative expiration date. For the relative expiration date, it allows specifying days, hours and minutes instead of just days. An expiration of less than one day is now supported. This enables senders of an envelope to set the exact expiration timestamp of an envelope, e.g. for offers valid just till an exact time like midnight.

With release 20.14 a year ago, the REST API Versions /v1 and /v2 have been marked as obsolete/deprecated and a migration guide has been published. With the 21.16 release, those versions have been removed:

• /api/v1 (also accessible via /api/v1.0)
• /api/v2 (also accessible via /api/v2.0)

The REST migration guide, which contains also some more information about the different API versions and in particular about the differences from version 1.0 or 2.0 to newer versions, is available here:

Migration Guide

Please mind that the guide describes the migration to v4, but similar functionality will also be applicable for a migration to /v5. The swagger documentation, which is our REST API reference documentation, is available here:

https://demo.esignanywhere.net/Api/swagger/ui/index

When storing signed documents in a document management system (DMS), a tagging of the document(s) is common and mandatory to find the document again. While eSignAnyWhere already supported providing metadata in API integrations, older versions allowed the sender via WebUI to specify just one free-text metadata field with the recommendation to put an XML structure into it. Since 20.52, it is possible to integrate custom tagging implementations, which consider structures and allowed values predefined in a DMS. It allows organization admins to define a custom page, being presented to the sender before sending an envelope for signing.

The UI of a metadata tagging form (or other before-send redirect page) can be aligned to the eSAW UI look and feel, or be aligned e.g. with your DMS. Consequently, the new change now allows defining metadata in templates. This can be used to set defaults, which are considered in a custom tagging page when a template was used to create the draft. Beside DMS tagging, metadata can be used also to define other values necessary for post-processing by a callback handler. Any additional information/description can be added into the metadata section of an envelope.

You can now configure the following viewer preference: AcceptAgreementDisabledUntilRequiredActionsDone

Note: You can configure the viewer preference in the UI in the section organization->design of the document viewer. Download the design template or your current design and set the variable AcceptAgreementDisabledUntilRequiredActionsDone to 0,

to disable this preference or to 1, to enable this preference. You can also configure this viewer preference via API. Therefore, just add the following variable in the section viewer preferences like it is shown in the next sample:

"ViewerPreferences": {
          "AcceptAgreementDisabledUntilRequiredActionsDone": true,
          "VisibleAreaOptions": {
            "AllowedDomain": "*",
            "Enabled": false
          }         },

Please also make sure that the "Allow Electronic Record and Signature Disclosure" is enabled:

If the preference is set to true and the agreement configuration is enabled the signer will then see the following interface before accessing the document:

On-premise only.

Organization Export

Allows you to export an organization’s settings and use it to create/update other organizations. Organizations can be exported, created and updated using the DB Manager or Admin Web. The result of the export operation is a Zip file that holds 3 files as follows:

• Logo – The organization logo. (If the organization has no logo, then this file will be missing from the Zip file)
• CustomizationZip.zip – Customization file of the organization. (If customization is not allowed for the organization, then this file will be missing from the Zip file)
• ExportedSettings.xml -The actual settings of the organization in XML format.

Organization Import

There are two options for organization import:

• Create new organization using the exported data of other organization.
• Update an existing organization with the exported data of other organization.

The update process will skip updating the settings below (even if they are in the xml file) since they can affect ongoing/draft envelopes.

• OAuth settings
• Saml settings
• Bank Id settings
• SwissCom settings
• Disposable certificate settings

Note: Data such as envelopes, address book etc. are not supported with the export/import of the organization.

If you use lean disposable via API, you have to provide the document issuing country instead of the country of residence. Therefore, we introduced the DocumentIssuingCountry via API. For compatibility with existing implementations, we allow to use the field CountryOfResidence but for legal reasons you also have to provide here (when using lean disposable) the country which issued the identification document.

If you do not use lean disposable (but consider that the “traditional” non-lean disposable should be used only in exceptional cases), you have to continue using the field CountryOfResidence as in the past.

This plugin provides a generic way of integrating external (remote) signatures. Please see the following supported features:

• Signing types (defined by the plugin implementation)
  • User signing
  • Batch signing
  • Automatic signing
• Authentication
  • Using dynamic data fields
    • Types: Text, Phone number, Number, List (dropdown), Email, Password
  • Using external system (redirection to external URI)
  • Using external app (e.g. push notification) + callback receiver
• Signing method
  • Hash signing only via the plugin
  • Hash signing only via the default SSP integration

For more information about the configuration in the UI please have a look at the Electronic Signature Guide, the Signer Guide and the User Guide.
For more information about the configuration with REST API please have a look at the Beginner Guide. There you can find a sample configuration.

Previously the API authorization consisted of two parameters (OrganizationKey and UserLoginName). This has been reduced to a single parameter; an API Token. This token is individual for each user and can be created/updated/disabled/deleted on a new Page (ApiToken/Index->My Tokens). A user can have multiple API Tokens that allow a more granular usage of them. For example one token for integration A and another token for integration B.

Note: If a token is deleted it can not be recreated with the same token value.

Two possibilities for authentication:

1. Using the new API Token header (REST) or the API Token XML node (SOAP). Here
   only the API token is a valid value.
2. Use the OrganizationKey and the userLoginName for the authentication

For more information about the

• configuration in REST please have a look at Postman Guide
• configuration in SOAP please have a look at Hello World Guide
• generation  of a new Api token please have a look at Setting/User Guide

You can now also use the driving license as an identification type. This new identification
type is available in the UI as well as in the API.

For more information about the disposable certificate please also have a look at the Beginner Guide.

The bulk signing assistant is a feature that allows you to sign multiple documents with one click.

Note: The bulk signing assistant (eBSA) currently does not support the full set of features of eSignAnyWhere envelopes and signature methods. It is limited to

• Envelopes without authentication
• Envelopes that use Click2Sign as the only signature variant
• Only envelopes that do not require confirming an agreements dialog (Terms&Conditions) first

Please see also this guide: Bulk signing assistant

You can now find the setting in your organization to lock form fields. If you prevent editing form fields after the envelope is finished the form fields in the PDF are all read only. Therefore, after locking the form fields (after the final workstep), the form fields are not editable any more with other PDF tools.
For more information please have a look at this page.

You can also lock form fields with the API. Therefore, just add the following before the node “steps” in REST:

"LockFormFieldsAtEnvelopeFinish": true,

Or in SOAP:

<lockFormFieldsAtEnvelopeFinish>true</lockFormFieldsAtEnvelopeFinish>

In your organization settings you can now select required authentication methods. You can either select any or a specific authentication.

Moreover you can set the following

• Force input of the phone number when using SMS-OTP authentication
• Allow skipping forced authentication upon using biometric signatures
• Allow skipping forced authentication upon using disposable certificate, remote certificate or local certificate

For more information please have a look at this page.

You can find this feature in your organization settings in the section “Testing Phase Features”.
There you can allow to copy the viewer link from the envelope details page. If the user signs the envelope via the copy viewer link, then this information is also shown in the audit trail.
For more information about the clipboard please have a look at this page.

You can now define hyperlinks for your document with API. The next lines of code show you a sample configuration of one hyperlink:

"HyperLinks": [
\t\t{
\t\t "Id": "c238bd01-78ca-4958-a6dc-957fed629aa0",
\t\t "DocRefNumber": 1,
\t\t "PositionPage": 1,
\t         "Uri": "https://www.esignanywhere.net/",
\t\t\t"Position": {
\t\t\t\t"PositionX": 346.0,
\t\t\t\t"PositionY": 707.0
\t\t\t\t    },
\t\t\t "Size": {
\t\t\t\t"Height": 15.0,
\t\t\t\t"Width": 152.0
\t\t\t\t }
\t\t}
\t      ]

For general information about the hyperlinks please have a look at: Hyperlinks

The email template configuration in the product changed. Also some new placeholders were added. For more information please have a look at: Settings and Customizing

or in the product in the following section: Settings->Email Templates, there you will find a new section with all possible placeholders for each template. You can copy the placeholders and past it in your template.

The sender of an envelope can define wether the recipient of the envelope has access again after finishing and closing the envelope. For more information about the process of opening documents and finishing them please have a look at: Signer Guide

Links are now supported in the disclaimer dialog. For  more information please have a look at: Beginner Guide

You can now choose between the following five configurations for a Batch signature:

• Simple Batch
• Signature List (unselected)
• Signature List (preselected)
• Signature List (selected, required mandatory)
• Signature List (unselected, required mandatory)

We added the last two modes for mandatory fields (selected and unselected). This makes it possible to distinguish between mandatory and voluntary fields.

Therefore, the selected means that the user can select/deselect only signatures which are not required. All signatures are initially selected. The unselected means that the user can select/deselect only signatures which are not required. All non required signatures are initially deselected.

For more information please have a look at Signer Guide

PAdES configurations were added to the organization settings. There you can choose between the following levels:

• B
• T
• LT
• LTA

For detailed information please have a look at Settings and Customizing

There you can find all descriptions for the different levels.

You can now configure an A-TRUST signature in your workstep configuration. For more information please have a look at the Beginner Guide

In this guide you can also find a sample configuration for an A-TRUST signature.

If you are using eSAW on premise or in a private SaaS and use the SIGNificant Kiosk, you can use new features now:

• Combobox
• Listbox

The API caching now returns cached results in the case the same request is executed again too fast (e.g. after just some milliseconds).

The viewer supports new batch signature options, where the signer gets a list of the batch signature, either preselected or deselected. The original batch signature dialog is still available.

The new license management allows you to set warning notifications if the license or the envelope limit expires. You can even set a callback for an envelope limit warning.

If you are using eSAW on premise or in a private SaaS and use the SIGNificant Kiosk, you can use new features: SMS-OTP, Disposable and a PushTan integration.

You can easily change now holder information and validate the information in advance.

If you are using callbacks for your integration, you can set now basic authentication for your callbacks. Moreover, you define a pattern to define different callback-authentications.

The SAW Viewer allows now a local certificate verification.

We improved again the performance of our solution to provide you an excellent user experience.

We redesigned the SAW Viewer to enhance the usability and user experience. For more details check the special SignAnyWhere Viewer 2019 page.

We optimized the usage of the disposable certificate and how it is integrated.

We reworked the team feature, due some customer feedback. We optimized the sharing between teams, to prevent the sharing of all documents of two (or more) teams with a shared team-member. Moreover a hierarchy is now possible: (1) see all documents up & down or (2) see documents only down (“team lead”, but not seeing sent documents of my manager).

You can now view and export your organization’s statistics in the license section of the settings (accessible for user managers).

You can now access the license data via API. For SOAP we have the GetLicenseState_v1 and for REST V4+ V4/license. The response will be the type of the license, expiration date, status about the documents and users.

We added a new API call to unlock a parallel recipient to be opened by others again. Older versions only allowed it manually via UI, now you can integrate or automate it yourself. SOAP is called UnlockEnvelope_v1 and REST is called V4/envelope/{envelopeId}/unlock.

We added a new SAW Viewer Policy AutoStartGuiding, which allows you to start automatically the integrated guiding. This enables a use case, where the document loads and directly jumps to the first signature field.

We improved the UI of eSAW to allow a better user experience (e.g. license page).

We changed the default email template to a new one. For existing organizations, the set template will not be changed, just for new organizations or if you reset the template.

We integrated the Swedish BankID for authentication. Please contact us if you want to know more about it.

We improved the overall systems performance (database optimization, document processing, data management).

You can now optionally attach the document to the audit trail. So you have the final & signed document as PDF attachment in the audit trail. Note: this will increase the size of the audit trail.

This feature is only available via API in the <envelope> section, per default it is disabled (0).

<attachSignedDocumentsToEnvelopeLog>1</attachSignedDocumentsToEnvelopeLog>

You are able to overwrite the signature disclosure (set up via eSAW UI in the organization settings) via API. So you can define unique information per envelope or recipient (e.g. for internal users disable the signature disclosure).

This is configured via API in the <step> section of the envelope.

<step>
  ...
  <useDefaultAgreements>true</useDefaultAgreements>
  ...
</step>

useDefaultAgreements – true (default value): use the default signature disclosure of the organization (the configuration in the workstepConfiguration is ignored)

useDefaultAgreements – false: use the setting of the workstepConfiguration (overwrite). If the config is empty, no signature disclosure is set for the recipient.

Optimization of the on-premise setup of eSignAnyWhere.

Improvements of SAW Viewer

• Optimized mobile OTP forms
• BankID support
• Added check for enabled cookies
• Added disposable certificate disclaimer text (FR/PT)
• New languages: Polish, Chinese
• Security enhancement
• Fixed QR code for SoP (had some issues with some browsers)
• Optimized tablet view of the menu
• Optimized image generation for Click2Sign, Draw2Sign and Type2Sign

via Hotfix

• Reject message can be empty
• FinishAction also for Reject and Delegate
• fixed Translation issues

The security of your documents is in our primary focus. Therefore, we improved the security of eSignAnyWhere to ensure the security of your documents.

We improved the overall performance of eSignAnyWhere for excellent user experience and increased scalability to grant you high performance, even in critical high load scenarios.

Improvements for point of sale use cases. This includes for example optimizations for timeouts in the clients and data handling for fast responses in a workflow.

eSignAnyWhere allows you to define a logout redirect page. So you can integrate eSAW in your intranet applications and set a specific logout page for your users.

We improved the installation procedure for on premise installations of eSignAnyWhere.

We added for API use cases the support of SwissCom certificates (personal and organization certificates).

• Security Improvements (CSS, Input Validation, brute-force PIN prevention)
• Visual optimization of the disposable certificate form
• New Language: Bulgarian
• New viewer preference: PhoneNumberInputSettings
• Technical: switched to XLIF format for language support
• fixed some UI bugs

via Hotfix:

• fixed Draw2Sign & Type2Sign placement
• fixed QR code for SoP for some browsers

It is possible (as advanced feature) to use automatic remote signatures. The user manager of an organization can add automatic remote signature profiles, which can be used for any workflow as a recipient (recipient type “Automatic”). This recipient signs automatically the signatures and the workflow continues automatically. Details see Beginner Guide.

It is possible to use the replace recipient method (ReplaceRecipient_v1) to change the workstepconfiguration. It is only possible to change the workstep configuration if the envelope was created via API and the recipient is a signer.

eSignAnyWhere 3.2 now fully supports the SIGNificant Biometric Server for signature verification, including the SignAnyWhere Viewer and the audit trail file. This feature is not available on significant.com and requires a private SaaS or on premise instance of eSignAnyWhere.

The SAML support was extended to allow easier user management directly in the UI of eSignAnyWhere. SAML requires a private SaaS or on premise instance of eSignAnyWhere.

Automatic Delegation is an advanced feature, which allows the user to define an automatic delegation. So all of the user’s signing requests are automatically forwarded to a substitute, which is also a user of the organization. An optional end date automatically disables the automatic delegation.

• UI optimized resizing of window behavior
• Open source information added in the SAW Viewer
• Fixed biometric signature under certain use cases
• Optimized UI for authentication
• Error handling of uploading attachments improved
• Improved error messages
• Device Driver UI optimized
• bugfix for batch signature

via Hotfix:

• fixed some translations
• fixed navigation bar, when maximizing window
• fixed rejecting of document for specific use cases

Bulk envelopes allow you to send an envelope to multiple signers. The workflow splits with the bulk recipient, so that you will receive unique signed documents for each bulk recipient. This feature is perfect for letting one document (e.g. a new company policy) sign by many recipients. This feature is not available with basic subscription, so please contact your Namirial sales. Details in the Bulk Use Case.

It is possible to define P7M signers in eSignAnywhere. This allows you to define at the end of a signing workflow to define signers with P7M. Details see in the envelope structure guide.

In addition to our SOAP interface a new REST/JSON Swagger interface is available. See www.significant.com/api

Added support for Form-Field-Validation. Six types are supported: No-Validation, Date, Email, Number, Phone and Time. It is only supported with the Placeholder Use Case and via workstep configuration.

The Retention Period per organization sets an automatic timelimit for deleting old envelopes.

You can select now the email sender name. In the organization settings you can select between three options: (1) firstname lastname via eSignAnywhere (2) Organizationname via eSignAnywhere (3) eSignAnywhere. On-premise or private SaaS customer can replace eSignAnywhere with their desired text. Via API you can select the option for each envelope.

<envelope>
   ...
   <displayedEmailSender></displayedEmailSender>
   ...
</envelope>

If the displayedEmailSender is empty only eSignAnywhere is used. If the field is not empty, this text will be used before ” via eSignAnywhere”. Without displayedEmailSender the organization default setting is used.

• form field validation
• added undo option
• added languages: Spanish, Portugese
• updated translations
• improvements for local certificate signing
• allow configuration of date format for picture signature types
• fixed UI issues for some devices (mobile, tablet or browsers)
• fixed device driver issues
• fixed attachment with hidden documents
• fixed Finish button visibility after finished document
• fixed error for some specific policies
• fixed the guiding for disabled elements
• fixed local time issue

via Hotfix:

• fixed a finish document issue
• fix batch signature with OTP issue
• optimized Device Driver integration

With this feature you are able to hide specific documents from specific recipients. So you can create an envelope with two documents, where the first signer just can see the first document, the second signer only the second and the third can see all documents. You can configure it in the eSAW UI or via API.

API Configuration is done via envelope/steps/step/documentOption; Sample:

<envelope>
   ...
   <steps>
      <step>
         <emailBodyExtra>
         </emailBodyExtra>
         <orderIndex>1</orderIndex>
         <documentOptions>
             <documentOption docRef="1">
                 <isHidden>1</isHidden>
             </documentOption>
             <documentOption docRef="2">
                 <isHidden>1</isHidden>
             </documentOption>
         </documentOptions>
         <recipientType>Signer</recipientType>
         <workstepConfiguration>...</workstepConfiguration>
         <recipients>
            <recipient>
               <eMail>next@recipient.domain</eMail>
               ...
            </recipient>
         </recipients>
      </step>
   </steps>
</envelope>

This feature is not available in all subscriptions.

A new signature type is now available. You can define a signature field, which sends a SMS-OTP in the moment of signing to have a second factor for it. Basically, it is a Click2Sign with an SMS-OTP. You can select it via UI (SMS-OTP Signature Type) or via API:

<recipient>
...
  <smsOtpAdditionalInformation>
    <phoneMobile>...</phoneMobile> <!-- naming consistent with "disposableCertificateAdditionalInformation" -->
  </smsOtpAdditionalInformation>
</recipient>

Moreover, in the workstep config the type must be TransactionCode, with trModType set to TransactionCodeSenderPlugin.

This feature is not available in all subscriptions.

For on premise and private SaaS it is possible to configure custom links for notifications. So the workstepRedirector can support your apps to open directly the workstep. For more details contact your Namirial consultant.

Acknowledge recipients are included in the “send finished documents to all signers” checkbox in the eSAW UI (and it is renamed to support also acknowledge recipients).

If you are generating a workflow, where a recipient has to enter data and upload a file (as PDF attachment), you can now directly access the file via eSAW API. Call the getEnvelopeById function to retrieve information about the attachment and the file Id for downloading.

It is possible to set a behavior to confirm reading of a document.

Set in the WorkstepConfiguration (for a recipient) the following Task (in workstepConfigurationPolicyWorkstepTasks):

<Task enabled="1" completed="0" required="1" id="847a3d4a-da2c-46f4-8c8c-a9edaa06c29b" displayName="your text for this task" DocRefNumber="1" type="ConfirmReading" />

The task must be the first and required!

Then you have to create the ReadingTaskInfo (directly in the WorkstepConfiguration) with attribute AllDocuments=”1″:

<ReadingTaskInfo positionUnit="PdfUnits" positionReferenceCorner="Upper_Left">
\t<ReadingTask id="847a3d4a-da2c-46f4-8c8c-a9edaa06c29b" pageNumber="1" DocRefNumber="1" AllPages="0" AllDocuments="1" />
</ReadingTaskInfo>

You retrieve now also a callback, when an envelope expires.

The getEnvelopeById contains now more details about the envelope (e.g. recipient details, signing date and authentication).

Advanced document tags now support an offset, to define a relative positioning of the element. Offset is defined as number (double), in Units points and starts at the lower left position. Positive values x are moving to the right and positive values y are moving up. e.g.

:offset(x=-10.5,y=50.6)

• support of hidden documents
• support for confirm reading
• reworked rendering of some signature types (local certificate, remote signature, disposable signature)
• fixed OTP signature issue with wrong OTP
• reworked zoom handling
• fixed a delegation issue (delege to yourself)
• optimized UI for devices (mobile, tablet, browsers)

via Hotfix:

• fixed translations
• reworked visual appearence of attachments
• added new viewer policies for customization
• fixed UI in landscape for mobile devices
• fixed OTP handling & errors
• fixed OAuth/SAML with a port in configuration
• upgraded Device Driver protocol level
• fixed a batch disposable certificate issue
• enhancements for debug mode
• client server communcation optimization (e.g. retry for calls)

The Audit Trail supports now different languages:

• SignAnywhere Viewer (Signer-Interface): Audit Trail is rendered in the language of the viewer
• eSignAnywhere UI: Audit Trail is rendered in the users UI language. Moreover it contains a language independent XML representation.
• API: via API you can download a signed XML, containing the Audit Trail data (via GetEnvelopeById as logXmlDocumentId)

You can use SAML to authenticate signers in the SignAnywhere Viewer (Signer Interface). You configure the SAML provider and can use it via UI and API. Click here for details about the configuration for API. Contact your Namirial sales for enabling SAML support.

This feature is not available in all subscriptions.

Only private SaaS and on premise: each organization of the instance can have their own biometric encryption key.

It is possible to delete recipients of already started workflows, which did not yet sign the document. This is available in the detail view of an envelope in eSignAnywhere.

It is now possible to show a permanent reject button in the menu. This can be configured via customization with the new parameter DisplayRejectButtonInLeftBar.

With OAuth2 it is now possible to do an authentication check. So you can force that a specific userId has to authenticate via OAuth2 provider.

E.g. userId=123 of provider CustomOAuthService has to authenticate. If another user authenticates it is rejected. Just a user with userId=123 is accepted.

See Envelope XML Guide to see how you configure it via API.

This feature is not available in all subscriptions.

You can now, in addition to the envelope audit trail, download for each file a specific audit trail via API (GetEnvelopeById in section completedDocuments). You can enable it in the organization settings.

If you create an envelope within the eSAW UI, you can now download the complete envelope XML including the workstep configurations for your envelope. Therefore you have to be a “Developer”, which can be set up by a user manager in the account settings. Then you are able to download the XML at the end of the envelope-sending-process and in the envelope details page.

New types of callbacks are now available. See documentation for details.

The on premise version of eSignAnyWhere supports now different organisations with just one instance.

Full support of SIGNificant device driver. So you can use now signature pads or local certificates with eSAW as a signer.

New eSAW Viewer settings are available. For example, you can define now to automatically finish a document when the last signature was applied or configure the download document dialog. See here for details.

The performance of eSAW was improved. For example is the generation of the Audit Log optimized and the envelope-postprocessing, if no email is sent, done with highest priority.

GetEnvelopeById contains the reason about rejection or delegation.

<recipient>
\t<status>Rejected</status>
\t<rejectReason>...</rejectReason>
</recipient>

<recipient>
\t<status>Delegated</status>
\t<delegateReason>...</delegateReason>
</recipient>

We added the support of PDF form fields in the designer. So you can add text fields, radio buttons, checkboxes, lists and many more directly in the designer by drag and drop. You can select the behavior similar to signature fields (select a recipient) and configure some properties of them. See the User Guide for more information.

New advanced tags are supported to predefine in the documents signature fields and form fields. They are more complex than the easy to use Signature Strings (see User Guide). The advanced tags are documented in the Placeholder Use Case. For the advanced tags a new API function PrepareSendEnvelopeSteps_v1 is available.

It is possible to use a template and replace the document of the template. The position of the fields (e.g. signature fields) are kept. See the User Guide for more details.

Registered signers are able to upload a picture of their signature (e.g. written on paper) and import it to eSignAnyWhere. eSignAnyWhere enables an editor to modify and adopt the signature (crop, rotate, cut) to be used as signature for signing. See User-Guide for more details.

To avoid filling up email postboxes, eSAW now sends the documents as attachments, as long as they are under 2,5 MB. If larger documents are used, just a link to the document is sent. This link is valid for 90 days to download the file.

You can now manage the users of your organisation via API. See API Reference - SOAP for more information.

You can now use the FindEnvelopes_v2 function for advanced search via API. See the API Reference - SOAP for more information.

For complex integration it is now possible to disable sending emails for a specific recipient (e.g. in a POS scenario). See Integration for details.

You can add now custom buttons in the signing interface (the eSAW Viewer) to add custom functionality.

We added some configurable settings, such as avoiding dialogs or settings for Batch-Signing, for the eSAW Viewer. So you can define the behavior of the signers-view. See this documentation for more details.