This page shows the features with the respective versions. For detailed information about LTS (Long-Term-Support) please have a look at: eSignAnyWhere Release Policy
Current LTS version: 22.76

Explanation of Feature Release and LTS Release:

Feature Release: New functionality, lower priority fixes

Long-Term-Support-Release (LTS): 2 years of guaranteed hotfixes for critical bugs and Critical/High security findings.








Feature Release

eSignAnyWhere 24.10

Date: March 2024

Beside, focusing on stabilizing and improving existing features to make them even better to use, this release additionally introduces CIE signing, which refers to process of digitally signing documents or transactions using the Italian electronic identity card.

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):

Local File Based Certificate

Local File Based data







Feature Release

eSignAnyWhere 23.52

Date: February 2024

We are excited to announce this release that brings a concentrated effort on stabilizing and enhancing existing features to deliver an even smoother user experience. Our primary goal with this release is to make your interactions with eSignAnyWhere more seamless.

  1. Stabilization of existing features: We have dedicated significant effort to stabilize and fortify the core functionalities you rely on every day. By addressing potential issues and optimizing performance, we aim to provide a more robust and dependable user experience. We have diligently worked on resolving various minor issues. This includes addressing bugs, enhancing error handling, and refining the overall user interface to smooth out any potential disruptions.
  2. Feature Improvement: In addition to stabilization, we have fine-tuned and improved several existing features. This ensures that the features are now even more user-friendly and efficient. 
  3. Preparing for upcoming LTS version: This release sets the groundwork for our upcoming Long-Term Support (LTS) version. By focusing on stability and fixing minor issues, we are laying a solid foundation for a LTS version that not only meets but exceeds your expectations in terms of reliability and performance.

REST API /v3 and /v4 DEPRECATION: The 23.76 (published March 2024) will be the last LTS version that includes these API versions. By early June 2024, the REST API routes to v3/v4 will be deactivated on DEMO. Early December 2024, the REST API routes to v3/v4 will be removed from feature stream releases. Note that there is no date communicated yet to discontinue REST APIv5 (and where v5 refers to v4 routes, these will still remain); however we recommend to use the /v6 API specification already. Moving from v4 to v5 is anticipated to be a minimal change.
For further information please also see the API Migration Guides






Feature Release

eSignAnyWhere 23.49

Date: December 2023

Beside, focusing on stabilizing and improving existing features to make them even better to use, this release additionally introduces the following:


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: Feature Flags#DigitalRemoteSignature


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.

Precondition is the following feature flag: Feature Flags#ActivityEngineCustomLocalizations







Feature Release

eSignAnyWhere 23.45

Date: November 2023

Beside, focusing on stabilizing and improving existing features to make them even better to use, this release additionally introduces the following. With these exciting updates, you will experience a platform that not only offers a more captivating visual experience but also provides you with greater control and insights into your organization's operations. It is time to embrace the benefits of these enhancements and take your user experience to the next level:

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


In this release, we are thrilled to introduce a feature that gives you more control and flexibility over your document sealing processes. With the new "AllowUsingCustomSealingCertificate" feature flag, you can now seamlessly enable or disable the configuration of a specific sealing certificate for each organization. This update not only streamlines your operations but also ensures that your organization's unique needs are met.
Please also see: Feature Flags#AllowUsingCustomSealingCertificate


We have taken a significant step to enhance your observability with the introduction of our new Envelope History feature. This feature is designed to provide you with comprehensive insights into the events related to an envelope, as well as detailed information on any events that may have encountered issues. The advantages are clear:
  • 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








Feature Release

eSignAnyWhere 23.40

October 2023

Beside, focusing on stabilizing and improving existing features to make them even better to use, this release additionally introduces the following:

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 Feature Flags#TypeToSignSignature.


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 Feature Flags#AllowUsingCustomTimeStampService 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.

OAuth Configuration Validation

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.






Feature Release

eSignAnyWhere 23.36

Date: September 2023

Beside, focusing on stabilizing and improving existing features to make them even better to use, this release additionally introduces the following:

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 Feature Flags#DrawToSignSignature.


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 Feature Flags#Backup 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:








Feature Release

eSignAnyWhere 23.31

Date: August 2023 (Shared SaaS: September)

Beside, focusing on stabilizing and improving existing features to make them even better to use, this release additionally introduces the following:

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 Feature Flags.


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 Namirial RemoteSignaturePlugin#SSPVersions%3E=23.31

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.








Feature Release

eSignAnyWhere 23.27

Date: July 2023

Beside, focusing on stabilizing and improving existing features to make them even better to use, this release additionally introduces the following:

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 Feature Flags and eSignAnyWhere AdminWeb (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.








Feature Release

eSignAnyWhere 23.23

Date: June 2023

Beside, focusing on stabilizing and improving existing features to make them even better to use, this release additionally introduces significant improvements to file storage management:

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 GlobalXML#Storage


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:

Please also see AdminWeb Organizations List.







Feature Release

eSignAnyWhere 23.18

Date: May 2023

Beside, focusing on stabilizing and improving existing features to make them even better to use, note the following features:

Improved the handling of the generic signing plugin. For general information about the generic signing plugin please see Generic Signing Plugin


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

Signature Fields Missing

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: On-Premise operating and system integrator guide (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









LTS Release

eSignAnyWhere 22.76 ("23 LTS")

Date: May 2023

LTS version based on the feature release version 22.52.






Feature Release

eSignAnyWhere 22.52

Date: March 2023

Beside, focusing on stabilizing and improving existing features to make them even better to use, note the following announcements:

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


New E-Mail Plugins required with different configuration location. Please see the Email Plugin Configuration for the different configuration location and the Email Plugin - Release Notes for the new E-Mail Plugins.


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.

Document Retention Limit

For detailed information see eSignAnyWhere AdminWeb#Details


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.







Feature Release

eSignAnyWhere 22.50

Date: Planned February 2023 (Release Candidate installed on Demo already)

Beside, focusing on stabilizing and improving existing features to make them even better to use, following new features are available with this version:

Api v6


API v5 will remain part of the product beyond the announced removal of v3, while REST API v6 is already available. For existing integrations, staying on API v5 is ok as long as no new features of v6 are required, but our recommendation is to start early to migrate to API v6 even in consideration of the effort, to be prepared for the situation when you need a new functionality that is available on API v6 only.

Please note: The guides listed below refer to the new api version 6. If documentation for versions below v6 are needed please have a look at: Outdated documentation

The changes between REST API v5 and v6 require bigger changes of the API client implementations, as this version switch addressed many known disadvantages of the v3-v5 API versions. For information about conceptual changes and changes on method level please see the Migrate REST API clients from v5 to v6.

Addressing some conceptual changes also here:

  • All naming in the API, on method level and inside the models, have been reviewed (and most of them have been changed) because we think consistent and simple wording helps to speed up the learning curve of the API users

  • We removed historic relics that come from technical architecture (e.g. „workstepConfiguration“) because API users shouldn't burn time by understanding internal concepts of our platform
  • We are using only the verbs GET and POST; and strictly avoid using PUT, PATCH, DELETE and other HTTP verbs again for simplicity, but also to avoid issues with some coding platforms and infrastructure configurations where customers reported issues in the past.

Additionally, with the  Tutorial: Hello World and the REST tutorial using Postman you get to know the basic concepts of the api. Please also see the Integration guide which contains different use cases as well as guides for starters: Integration Guide

UI extensions

For detailed information about the changes on existing form fields as well as information about new fields please have a look at: Designer Page

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.

Initial Settings


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

Settings

Please note that the organization api token can only be used with REST api version 1 to 5.


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:

Advanced Recipient Settings


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

Draft Agent Redirect Configuration

Signature fields


Please note the following:

The "Advanced Settings" tab allows to set additional parameters.

At the top of the advanced settings, the sender can change the appearance of the signature rendering:

  • Define the date format used for rendering the date on a signature field
    (this configuration will be ignored when defining a specific date format in a custom stamp imprint configuration that is applied organization wide for all or some signature types)

As many settings are different per signature type, the advanced settings tab also lists all signature types which have been allowed on the General tab. For each of the signature types, a settings section (which is by default collapsed) can be expanded. Some of these settings can be defined per signature type, but same options are available for all signature types to allow independent configuration.

UI signature validity in second. This setting is used by the following signature types:

  • DisposableCertificate
  • SwissComOnDemand
  • RemoteCertificate
  • OneTimePassword

Signature Settings OTP Validity



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.

Long Lived Disposable Certificate


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.

Biometric Signature Verification


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.

Local Certificate Filter


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:

Please note: If "Extra Information" is disabled, all other variables (such as "Name", "IP address" etc.) will be automatically disabled as well and no information will be displayed as stamp imprint. 

  • 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: WSC HOWTO BankID Plugin (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.






Feature Release

eSignAnyWhere 22.28

Date: July 2022

Beside, focusing on stabilizing and improving existing features to make them even better to use, following new features are available with this version:

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:

Lean Disposable

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.







LTS Release

eSignAnyWhere 21.76 ("22 LTS")

Date: May 2022

LTS version based on the feature release version 21.52.






Feature Release

eSignAnyWhere 21.52

Date: February 2022

The focus of this release is on stabilizing and improving existing features to make them even better to use. Please see all improvements in the following overview:

  • 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:

Document Upload With Predefined Syntax

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






Feature Release

eSignAnyWhere 21.31

Date: October 2021

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.

Please note that the actual functionality of the keypress depends on the context of the dialog!


"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.






Documentation change

Date: September 2021

Detailed documentation about how to configure SAML authentication for user authentication and signer authentication has been updated in the following guide: SAML Guide.








Documentation change

Date: August 2021

The documentation about metadata and the AdditionalClientWorkstepInformation has been updated in the following guide: Beginner Guide








Feature Release


eSignAnyWhere 21.27

In preparation

Date: Expected 24 August 2021


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:

OAuth Settings Overview


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

SwissCom On Demand Certificate Setting

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).

SwissCom On Demand Certificate Recipient

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

SwissCom On Demand Certificate Signature

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:

Must View Recipient Type






Feature Release


eSignAnyWhere 21.16

Date: April 2021

Please note: For detailed information about the 21.16 features please also see this release notes document.


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.


Organization administrators can now customize localization (especially text translations) per organization. It enables a higher level of customization and more adjustments of the SignAnyWhere Viewer (Signer Front-End). The front-end can now be adjusted to the company’s common wording.


The organization administrator can now define filters on intended-use of certificates, for envelopes containing local certificate (SmartCard) signing experience. With that filter configured, the list of selectable certificates can be restricted to the certificates relevant on a local market (e.g. if a local signature smartcard contains two or more certificates for different purposes, like signing and identification).


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.


A new dialog will let you choose between bulk recipients added in an envelope draft and bulk recipient list defined in a template. For example: If you add a template with a bulk to an envelope which already has a bulk included you will be asked if you want to continue with the bulk from the template or with the bulk from the envelope. This will help you with the process flow of bulk sending as you can now differentiate between the bulks of different envelopes.


With custom signature rendering layout configuration (stamp imprint configuration), an organization administrator can define how the stamp imprint on the signature image looks like (e.g. fonts, elements, layout etc). The new functionality allows to set organization wide background images (e.g. company logos) or define specific fonts for text added to the stamp imprint. While it has no impact on the legal levels of signatures (in EU, defined by eIDAS), a customer specific stamp imprint representation can create higher subjective trust and contract awareness of your customers.


This feature clears up ambiguities in the UI. Only those features are displayed which are actually possible with the given settings. Non-accessible features will be hidden to optimize the UI experience.


The “Generic Signing Plugin” (GSP) allows implementation of custom 3rd party signature creation implementations (HSM based, web service based, etc). It is typically used to integrate external CAs into eSignAnyWhere. A GSP based implementation of a 3rd party CA is available for envelopes created via eSAW API or via eSAW WebUI. New features and improvements allow wider usage of the GSP.









LTS Release

eSignAnyWhere 20.76 ("21 LTS")

Date: April 2021

LTS version based on the feature release version 20.52.







Feature Release

eSignAnyWhere 20.52

Date: December 2020

You can now create, update and send a draft via API. Therefore, with the new API calls you can prepare an envelope and send it at any time. Before sending you can also update the draft if some configuration should be changed.
For more information about how to create and send a draft via API please have a look at the following guide: Use Case Example Draft


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:

Agreements Configuration Overview

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:

Force Print Or Download


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.


eSignAnyWhere and SSP from now on separates between an “anonymized” and a “full” log file. On-Premise customers can share with us e.g. for analysis purposes the anonymized log file. Whereas offering SaaS, where anyhow a data processing agreement should exist, Namirial still has access to both log files but it allows sharing the non-anonymized log file with more people inside Namirial while the logs which contain personnel information will still be accessible only for a very restricted number of employees.Note that messages in log files and the error text returned e.g. in API calls (but not the error codes) will change in order to be more data privacy friendly.


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.












Documentation change

Date: November2020

The Beginner Guide has been expanded to include the following:
In the section “signatures” you can now also find an example (REST/SOAP) of a StampImprintConfiguration.


The Use Case Example Template has been expanded to include the following:
In the section “Override Radiobutton” you can now find an example (REST/SOAP) of how to override a radio button from a template.









Feature Release

eSignAnyWhere 20.42

Date: October 2020

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


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.


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


We declared SOAP as deprecated and therefore SOAP will not be included in versions after 21.76 (already postponed by one year, initially the 20.76 was announced). Latest release including SOAP API for eSAW will be 21.76, released in spring 2022 and with the software maintenance on 21.76 until spring 2024.
Therefore, we recommend REST technology for integration. Please see also the migration 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







Feature Release

eSignAnyWhere 20.28

Date: July 2020

We declared SOAP as deprecated and therefore SOAP will not be included in versions after 21.76 (already postponed by one year, initially the 20.76 was announced). Latest release including SOAP API for eSAW will be 21.76, released in spring 2022 and with the software maintenance on 21.76 until spring 2024.
Therefore, we recommend REST technology for integration. Please see also the migration guide.


In addition to the predefined roles and permissions you can now define your own roles. So, for example you can define a new role, where the user can manage and send envelopes, but not create the envelopes on their own. Or a role which can configure automatic remote signatures themselves, without being user managers. Moreover, you can also set the permissions for your roles.
For more information please have a look at this page.


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 configure a bankID signature field and a bankID authentication via api.
For more information about bankID and the configuration please have a look at this page.










Feature Release

eSignAnyWhere 20.14

Date: April 2020

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


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


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


We recommend REST technology for integration. However, we will offer SOAP as well and SOAP is still being maintained. When we decide to declare SOAP as deprecated in the future, we will publish further information on this page. In this case, we will grant enough time before SOAP gets discontinued.








LTS Release


eSignAnyWhere 19.76 ("20 LTS")

Date: April 2020 (Release Candidate)

LTS version based on the feature release version 3.7.






Feature Release

eSignAnyWhere 3.7

Date: January 2020

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).


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








Feature Release

eSignAnyWhere 3.6

Date: September 2019




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.








Feature Release

eSignAnyWhere 3.5

Date: July 2019




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.








Feature Release

eSignAnyWhere 3.4

Date: February 2019




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








Feature Release

eSignAnyWhere 3.3

Date: November 2018




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









Feature Release

eSignAnyWhere 3.2

Date: August 2018




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








Feature Release

eSignAnyWhere 3.1

Date: May 2018




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








Feature Release

eSignAnyWhere 3.0

Date: February 2018




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)









Feature Release

eSignAnyWhere 2.6

Date: January 2018




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.


You are able to set a default callback URL in the Organization settings of eSAW. So you can send out envelopes via eSAW UI and perform an integration on your side (e.g. an automatic archiving of the documents).








Feature Release

eSignAnyWhere 2.5

Date: September 2017




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>










Feature Release

eSignAnyWhere 2.4

Date: July 2017




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.