• ‍Improved Fallback SMS

Now, fallback SMS messages will be automatically initiated in all instances where WhatsApp communication encounters issues, including API errors and template-related challenges. This ensures consistent communication delivery and mitigates potential disruptions in messaging flow. Previously, fallback SMS messages were triggered only when the invitee's phone number was not linked with WhatsApp.

SMS and WhatsApp parallel communication will give users more control over the communication channel and ensure reliable delivery of messages to the invitees.

• Verifies the identity of document invitees actively participating in the eSigning process.
• Ensures the individual in front of the device is live and authentic.
• Smart User Liveliness can be enabled alongside Face Capture and Face Match, ensuring integrated and efficient functionality and eliminating the need for multiple face capture attempts.
• To ensure success, a Liveliness Confidence Score threshold must be met.
• Strengthens security measures during the document signing journey.

Behind the scenes, a sophisticated system diligently detects and rejects spoof attempts, whether tangible (printed photos, masks, identity documents) or digital (pre-recorded videos, photos).

When do NeSL invitations fail

NeSL invitations fail in two scenarios-

• Error in the NeSL form: In this scenario, the user has no option but to fill the form again and resend it. 
• Network/Server issue while making an API call to NeSL: In this scenario, we allow clients to resend the same invitation using the Retry button on the Details Page. We have created an API to retry such NeSL invitations.

‍

With these updates, API clients can effectively replicate our Details Page for NeSL invitations, eliminating the need to visit the page for NeSL-related tasks.

‍

‍

• Add dynamic fields to your PDF using drag and drop editor‍

Now you don’t need to configure fields in-line while recreating the document.

PDF templates allow you to simply drag and drop the field wherever required on the PDF.

‍

• You can choose from a variety of fields to accommodate all of your requirements: Available fields are:‍

         1. Text field

        2. Dropdown

        3. Radio Button

        4. Checkbox

        5. Date

        6. Image attachment

‍

Knowledge Base Article - How to Create a PDF Template?

1. Sending Journey

1. Toggle on "NeSL’s eBG Flow" on the 'Create' screen.

‍

‍

2. After adding the required signing invitees (with or without NeSL signing type), navigate to Signing Journey Options and toggle on "Number of NeSL parties." You can specify the number of total parties for stamping-only flows or non-signing parties for partial signing via NeSL here.

‍

‍

3. Fill out the NeSL form or upload a NeSL Excel document.

4. New fields in the form include Event type, Is Individual, Signatory Gender, Expiry Date, and Claim Expiry Date.

5. A new Party section is available on this screen with the same number of placeholders as mentioned in the Signing Journey Options on the previous screen.

‍

‍

‍

6. After completing the form, the document can be sent to the participants.

‍

2. Signing Journey

1. Signing invitations will be sent only to the participants added in the invitee section.

2. Parties not added as invitees in step two (Invite) will not receive the signing link but will receive final mail communication for eBG details.

3. The remainder of the signing journey remains the same as before.

‍

Why is this update important?

1. This update aligns with the standard market practice where banks typically do not require debtors and beneficiaries to sign bank guarantees. It's primarily the responsibility of bank employees to sign. With this update, our bank clients can replicate this standard practice digitally.

2. NeSL now offers the option to use its platform solely for stamping for eBG, a choice that many banks are eager to embrace due to the simplicity and efficiency of stamping flow. This feature enables clients to leverage NeSL for stamping and Leegality for signing, offering a versatile solution.

‍

Additional Points

1. NeSL parties can be used for both stamping-only and partial stamping flows.

2. In the case of stamping-only flows, the signing process commences once stamping is completed, which is an automatic process taking only 2-3 seconds on average after sending the document.

3. This module supports all available event types for eBG, including issuance, amendment, invocation, cancellation, and more

‍

New Update

Now, with this update, we have automated the process. Here's what you need to know about this update:

A. Continuous Monitoring: Transactions will now be automatically checked every 10 minutes, allowing us to swiftly respond to changing conditions.

B. Priority Logic: We've implemented a priority logic based on the following considerations:

   i. NSDL (Protean) as super-priority:

This ESP will maintain its position as the top priority, thanks to its quick Turnaround Time (TAT) and commitment to engagement. It will only be deprioritized if its success rate falls below a specified threshold (success rate threshold = 40%).

  ii. Auto-switch for OTPs only: This feature applies exclusively to OTP-based transactions and will not affect Bio, Iris, or Face authentication methods.

  iii. Global Level: Auto-switching will be applied globally, ensuring a consistent experience for most users. However, organizations with custom orders or specific ESP configurations will need to manage priority orders manually.

C. Notification: Whenever an ESP's priority order is switched, an automated email notification will be sent to relevant stakeholders.

D. ESP Activation/Deactivation: Activation and Deactivations of ESPs are not included in the scope of this feature. Only the priority order is impacted.

E. For App1 only: This feature will impact only app1 transactions. Sandbox and Preprod won't get impacted.

‍

Key Advantages

1. Reduced Turnaround Time: Quick adjustments to ESP priorities in case of dropping success rates will lead to faster transaction processing.

2. Less Manual Intervention: Our Support team will no longer need to manually monitor and adjust priority orders, freeing up their time for more strategic tasks.

3. Improved Client Relationships: With fewer escalations and smoother transactions, we expect to strengthen our client relationships.

‍

‍

How does it work?

Enable Smart name AI from department level settings to start using it.

The result of Smart name AI will appear on the details page as they currently do.

Existing Smart Name users can effortlessly upgrade to the new Smart Name AI with a simple toggle switch in settings once they have access!

‍

‍

‍

‍

‍

Impact on the Signing Journey:

Once applied, "Aadhaar First" transforms the signer journey:

‍

1. Signers will initially see only the Aadhaar eSign option.

2. eSign subtypes will be displayed according to the configured order.

3. After reaching the configured retry attempts for a subtype, the next subtype in the order will be shown. An attempt is counted when the user clicks on 'Sign Document' button before going to the ESP screen

‍

‍

4. Other eSign types (e.g., Virtual, Cloud DSC) will only be shown to the user after they have completed the retry attempts for all Aadhaar eSign subtypes.

‍

Example Scenario:

Imagine a sender selects prioritise Aadhaar and configures the invitee with the following details:

- Aadhaar OTP with 0 retry attempts at order 1

- Aadhaar BIO with 0 retry attempts at order 2

- Virtual

- Cloud DSC

- Doc Signer

‍

the signer journey will unfold as follows:

‍

‍

Step 1: Signer sees only Aadhaar with OTP in the first attempt, user goes to ESP screen and clicks on cancel or closes the tab

‍

‍

Step 2: Signer previews the document > Signer sees Aadhaar with both OTP and BIO > user goes to ESP screen and clicks on cancel or closes the tab.

‍

‍

Step 3: Signer previews the document > Signer can choose from other signing options (Virtual, Cloud DSC, and Doc Signer) in addition to Aadhaar with both OTP and BIO.

‍

To avoid completion of such a transaction and save the aforementioned eSign credits, we wanted to provide an additional level of check in NeSL eSign flow with verification, so that, incase of verification mismatch, the sender can have an option whether to proceed with signing or not.

‍

‍

The Solution-

We’ve added an additional config in the Account TAB in -
Account → Department → eSignatures → NeSL eSign → Settings button

‍

In Acceptance Condition dropdown, we’ve added a new config called “Accept but pause signing journey”

‍

If an admin selects this option for verification for any verification type, upon verification failure of NeSL signer, the NeSL eSign will be affixed to the document, but subsequent Non-NeSL active invitees should be made inactive.

‍

‍

If 'Pause signing journey' is enabled. if an NeSL signer fails verification and there are subsequent non-NeSL signers, then-

‍

> The subsequent non-NeSL signer will remain inactive even after the previous NeSL signer has signed.

> There would be an email triggered to the sender that verification has failed and the signing journey has been paused.

‍

Failed TAB:

In the Failed TAB, the failure reason will be 'Signed but Verification Failed'. This is the same as the Failure Reason provided when 'Accept but Respond with Result' is enabled as Acceptance Condition. This decision was taken keeping in mind the impact adding a new failure reason would have (scope increase in Report service) and the limited usecases for this scenario.

‍

Activity Logs

There will be a log recording when verification fails. the log will have the report type 'Signed But Verification Failed'

‍

Webhooks:

‍

We haven't updated the webhook payload incase 'Pause Signing Journey' is turned ON. We'll send the same webhook response which is sent incase 'Accept but Respond with Results' is configured at account level.

‍

An Admin who will be setting ‘Pause Signing Journey’ config ON will know exactly for which parameter they’ve set the config (pincode, title etc.). The integration done by the Admin’s organisation can consider next steps if a parameter’s (pincode) verification response comes as false.

‍

Sending Journey

1. These new options are available in Invitee > Invitee level/More Options > Enable security features > Capture GPS Location.

2. Senders can choose to enable location-based restriction, accuracy-based restriction, or both in New document Flow/Workflow/APIs/Excel Upload.

3. For accuracy-based restriction, an Accuracy Threshold is required, while location-based restriction requires coordinates in degrees format and a permissible radius (default values are shown as set in the Setup section).

‍

Signing Journey

1. During GPS location capture, these restriction checks are assessed.

2. Invitees can proceed only if the restrictions are not breached; otherwise, relevant messages are shown

‍

‍

‍

‍

‍

‍

Setup

1. To enable this feature for a client, simply grant them access in the Admin Panel and set the per-session cost.

2. Clients can manage settings from their Dashboard: Account> Department > Invitee Configurations> Enable WhatsApp for Communications with Signers

Sender Journey:

Senders can now activate WhatsApp for invitees in the sender journey, as illustrated below:

‍

‍

‍

Once the invitation is sent, you'll notice a WhatsApp icon next to the phone number, indicating that communications will be sent to the invitee via WhatsApp.

‍

Additionally, our new logs feature will keep the sender informed about the status of their messages (sent, delivered, read), allowing them to take the most relevant actions.

‍

Communications to Invitee

All communications during the signing journey will be sent exclusively via WhatsApp.

‍

The Improved Experience:

‍Now, error messages will only be displayed on the invitee card of the invitee who haven't signed the document yet and is active. This means you'll have a clear and accurate view of which invitee requires your attention, eliminating any confusion about the signing status of those who have already signed and those who are not active yet.

We have renamed NeSL Lending flows from ‘Individual’ and ‘Non-individual’ to ‘Individual Lending’ and ‘Non-Individual Lending’.
These changes have been made in the NeSL form Account Tab.

Changes in the Client Dashboard

1. The added profiles will be reflected in the client's Dashboard as well in Accounts Tab > Department > NeSL eSign Config

2. In the sending journey while updating the form, user will see the registration types according to the added profiles.

3. This is applicable on Excel uploads and API calls as well. Based on the registration type specified in the form/Excel/API, mapped profile and credentials will automatically apply.

‍

Here's what this enhancement means for you and our clients:

1. By enabling multiple profiles, we empower our BFSI clients who have diverse operations and want to operate from the same organisation, to efficiently handle different workflows, reducing the need for multiple accounts and simplifying overall management.

‍2. This also helps our CS team as they won't need to manage multiple accounts for the same organisation with more than one service types.

‍3. Lower time for onboarding the client. Setting up different accounts adds unnecessarily to the time to onboard the client. With this, time to onboard such clients will reduce.

With this new update, users can now upload a picture of a document with a signature anywhere on the page. The system will automatically detect the signature and draw a crop box around it. This feature will be especially helpful for users in rural areas who found the additional step of manually cropping the image around the signature to be time-consuming and tedious.

Additionally, this new feature also works with PAN cards where the signatures are clear and visible in good lighting conditions. We hope that this new update will make the Sign Upload feature even more accessible and user-friendly for all our users.

Things to note:

• A new parameter has been added to API 2.1 create request - revenueStampQuantity, where the quantity of revenue stamps to be attached needs to be mentioned.
• This parameter will appear in the excel template and API 3.0 create request when the workflow creator leaves this field blank (meaning it is to be filled at runtime)

In order to ensure backward compatibility "revenueStamp Quantity" if not passed will assume a value of 1 in the API since before this implementation customers did not need to pass this parameter to attach a single revenue stamp.

Compared to Lending flows (Individual or Non-Individual), the NeSL non-lending flow does not contain any loan details (such as loan number, sanction number, and EMI amount) in its form. However, the Stamp Details and Invitee Details remain the same for Non-Lending flow.

In the sending journey, if NeSL eSign type is enabled for a signer, after the invite page, senders need to fill the NeSL form. This form will now have a new option called ‘Operational Creditor’. We’ll be changing this name to ‘Non-Lending’ soon, so stay tuned! This option corresponds to the non-lending flow.

A few things to keep in mind:

1. Although this is the non-lending flow, while configuring ‘Contract Relation’ of the 1st invitee, NeSL has asked us to add Debtor as the value.
2. In Non-lending flow, the 1st invitee can be both, an individual OR an organisation (depending on the usecase). Depending on the value of ‘Legal Constitution’ and ‘Official Doc ID’ in Invitee Details, validations such as Registered/ Communication Address/ pincode will either be mandatory or optional

Please note that the non-lending flow cannot be used with NeSL Lending Credentials configured for your organization. If you wish to enable the non-lending flow, please contact our Support Team to change your credentials.

A. Profile IDs:

Please note, once configured we were appending these headers to all the webhook calls. But clients may require to:

1. add headers only to webhook call of certain documents/workflows

2. add different types of headers to different webhooks

‍

To cater to these needs:

1. At the time of configuring webhook headers, a Profile ID would now be generated.

2. This Profile ID would be shared with the clients over a secure email.

3. Senders can add this Profile ID in workflows, new documents Flows or API calls.

4. Only the invitations having an associated Profile ID would have the mapped additional headers in the webhook calls

‍

For APIs: this profile ID can be passed at this path: $.invitees[].webhook.profileId

‍

For Co-ordiante Picker Webhook: path: $.coordinate_picker_webhook_profileId

‍

For New Document and Workflow Configuration Flows: Go to Invitee Level Options > Add custom URLs and webhooks > Webhook Profile ID.

‍

B. Payload Encryption:

The Webhook Payload can be encrypted as per the clients' request. The following steps are required for encryption

1. Client shares their encryption request with a public key. This request would be configured in Leegality's system
2. And a Profile ID would be generated against it 
3. The sender can pass this profile ID (as mentioned in the section above)
4. The webhook payload would be encrypted using the client's public key and will be sent in encrypted form during the webhook calls
5. Clients will use the associated private key to decrypt the payload and access the information

‍

A little bit about encryption

Payload Encryption provides another layer of security to webhooks. We have used AES (Advanced Encryption Standard) Encryption Algorithm with CBC (Cipher Block Chaining) mode to encrypt the payloads of the webhook.

Using the client’s public key, a 256 bits AES key is encrypted and then this AES key is used to encrypt the payload.

Background-

Currently, clients have 2 ways of configuring a DocSigner Certificate:

1. Configure a Signature Certificate at the client's server end
2. Configure a Signature Certificate on the  Leegality's server end

‍

Till now, if a client wanted to configure their certificate at Leegality's server end, it required the customer to reach out to Leegality, and the doc signer was configured by Leegality’s team internally.

Now, we have provided a config for clients to seamlessly configure their Docsigner Certificate on Leegality's environment.

Using this functionality, customers can directly download audit trails from the dashboard without reaching out to our support team. 

The link will be accessible to the sender & invitees of the document, admins in the organization, and other users and CCs with whom the document has been shared.

‍

In the current process, all stamps are affixed together before the documents, which can be confusing for users who prefer the appearance of stamps affixed just before their corresponding document. With NeSL MultiDoc, each eStamp has a certificate number that is imprinted on the document it corresponds to, making it easy for users to identify which stamp corresponds to which document.

Note that you can attach multiple stamps to a single document.

Version 1 of this feature includes support in API 2.1 flow.

‍

Why do we need it?

Authentication is a standard process, especially for API calls from outside systems. Currently, 'private salt' allows clients to authenticate these calls. Clients, due to reasons like compatibility with their existing systems, may want to authenticate headers as well. Previously, we have received such requests from SIB (using Nucleus), Tata AIG, Grant Thronton, etc.

This should improve the onboarding process for our clients and make it smoother.

‍

What kind of parameters can be added to the headers?

Rather than allowing only a certain type of authentication method, we have productised this solution which is capable of supporting a wide variety of authentication from simple basic authentication via user ID and password to complicated OAuth2.0 via tokens. Clients can add both static and dynamic (fetched from an API) key-value pairs in the webhook headers

‍

How to configure the headers?

Step 1: Clients can share their authentication requirements over a secure email.

For static fields, expected key-value pairs would be required.

For dynamic fields (API fetched), API documentation and expected key-value pair would be required.

Step2: We will configure these from the backend and inform the client of the expected response

Step 3: Once deployed, clients should expect all their webhook calls to have these additional headers

‍For dynamic parameters, an API call will be made to the URL (shared by client in the API documentation) to fetch the required parameters in real time and they will be added to the headers like in the case of static parameters.

You can specify the number of revenue stamps you want to affix to your document when creating a new document via the dashboard or through APIs.

Dashboard Flows:

In the dashboard flows, you can specify the number of revenue stamps by entering the value in the "Number of Revenue Stamps" input field after enabling Revenue Stamps.

API Flows:
For API flows, a new parameter has been added to API 2.1 create request - revenueStampQuantity, where the quantity of revenue stamps to be attached needs to be mentioned.

In workflows, you can configure the revenue stamp quantity when creating the workflow, or alternatively pass the quantity when running the workflow via the dashboard or the API 3.0.

In order to ensure backward compatibility, if "revenueStamp Quantity" is not passed, we will assume a value of 1 in the API.

Things to note:

1. You need to create a stamp series for Revenue Stamp
2. Revenue Stamp will be available as a separate toggle once the stamp series is created
3. You can only add Revenue Stamps to a document, they cannot be added to a group.

The signing URL will be visible on the Details Page and will also be received in the 2.1/3.0 API response. 

Things of note:

• The email sent by Leegality with the signed URL can be customized and can support custom branding. You can offer this option to customers.
• The instructions email has been removed from the flow since we are now directly sending the signing URL to the signer.

Now a maximum of 10 IDs will be digitally imprinted on the document and the rest of the stamp IDs will be available in the document properties.

https://docs.leegality.com/v3#tag/API-3.1/paths/~1v3.1~1invitation~1activate/put
This API can activate any inactive invite when required. When to use this - when an intervening signer is unable to sign but the sender wants other signers to proceed with signing.

Typically banks and other financial systems require that the drawn signature resembles closely to the signature in their records for approval. 

Signature upload will be one of the virtual signs that can be configured where a user will be able to upload a signature drawn on a plain white paper.

This feature is useful for API integrations where customers have integrated the 2.1 API and need to pass page specific eSign coordinates, but who are unsure how many stamp papers will be added through group stamping. 

These customers can now pass "replicateStampCoordinates" as "true" and be assured that all stamp papers (regardless of how many get attached) carry the necessary eSign coordinates, without affecting eSign coordinates on other pages.

• Tick the checkbox while sending out invites and the contacts will be auto saved in your contact book. 
• You can also manually add contacts or use excel upload to bulk upload contacts. 
• You can label contacts and search by labels whenever needed 
• You can just start typing and choose from a dropdown of contacts to select the relevant contact. 
• Contacts from your organisation will be auto added in your Contact Book with the label "Organization" so you don't have to manually add your colleagues in the Contact Book
• You can also share or send contact details to these "Organization" contacts so that the process of adding contacts become smooth and speedy for the entire organization. 
• You can save a confidential contact as a secret contact in your contact book and others in the organization won’t be able to access or view it. 

Refer the knowledge bank article here for more info and screenshots: https://support.leegality.com/portal/en/kb/articles/contact-book

Previous Flow: 

1. Whenever a client has any issue with an NeSL sign invitation, they would message Leegality's support team the document ID. 
2. Support team would connect with Tech Team to get the Transaction ID for the aforementioned sign invitation. 
3. This transaction ID would be shared with NeSL to understand the reason for this error. 
4. NeSL's response would be communicated to the client. 

New Flow: 

Whenever a client has an issue with NeSL, the client can get the Transaction ID from the Details page and reach out to NeSL directly, without involving the support team & tech team 

OR 

1. The client can share transaction ID with the support team. 
2. The support team can then reach out to NeSL without involving the tech team.

A user can attach up to 10 eStamps having different values to the document for the NeSL sign instead of combining multiple stamp values into a single stamp paper. 

Multi-stamping is supported through Dashboard, API flow as well as excel flow.

Multi-Stamping solves for the following problems: 

• When we upload multiple PDFs in the sending journey, they’re merged as one single PDF. 
• If a client uploads 2 documents to be signed by NeSL eSign, the documents are merged into a single PDF, but the client will have to pay stamp duty for both the documents.

This will enable senders to distinguish between sign invitations that the invitee does not want to sign and sign invitations that the invitee has not yet opened/ forgotten to sign. 

This also opens another channel of communication between senders & invitees - messages which would have to be communicated offline can now be communicated inside the Leegality app.

You can also view the digital sign certificate in case the sign is successfully applied to the document. 

Note: This will be applicable only to new invitations created henceforth.

Look out for the parameter called neslData in the API documentation: https://docs.leegality.com/#tag/eSigning-Gateway/paths/~1sign~1request/post

2. NeSL e-stamp support has now been extended to a total of 19 states including West Bengal & Madhya Pradesh.

1) The new API covers a number of fields which were previously not covered in our Details API, including fields pertaining to new features like CC, Cloud DSC, Reviewer Rejection & Invitee Groups. 

2) The new API has been designed in a way that is highly scalable - when new fields are added in the future, we can simply upgrade the API without affecting existing integrations. This is expected to improve the roll-out time of new features being added to the Details API in the future. 

3) The new API is highly flexible - clients can pick & choose exactly those data points they want to receive, while ignoring the rest. 

Link: https://docs.leegality.com/v3#tag/API-3.1/paths/~1v3.1~1document~1details/get

When this toggle is enabled at the time of creating a workflow, the workflow runner will not be able to manually activate invitees or delete invitees. 

This will ensure that signers in the signing order after a reviewer will only be able to sign if the reviewer approves the document. 

This feature has been developed to enhance the robustness of the reviewer feature, and then solidify its use case as a "maker-checker". 

Note 1: This feature will be available to all clients who have reviewers enabled. 

Note 2: This feature is specific to workflows. Its not available in the New Document Flow/ API 2.1.

This will work for small textboxes and large textboxes. 

This upgrade is targeted towards template use cases where certain text fields (like name or address) are repeated in several places in a document. 

The new upgrade will allow users to easily fill multiple boxes with the same input value. 

This is a dashboard only feature without any changes to APIs or Excel Upload. A demo video will be released shortly.

This feature can be enabled for a particular organisation from the Config in Admin panel and then can be configured through

Accounts >>Department>> Invitee configs. 

The Coordinate picker sender can drop custom coordinates on the document before sending it to invitees via both Leegality Helper or SDK. 

Coordinate Picker feature is currently live for API 2.1 on Sandbox.

With this feature, the reviewer will have the capability to add a comment when the document is rejected. And this message will be reflected in the following: 

(i) Invitee details on the Document details page 

(ii) Signing update and Document completion mails triggered to the Reviewer, Sender and CC.

When the signer/reviewer accesses the URL after the group is completed, the message shown was:

"You do not have access to this URL". 

Now, the message has been updated to:

"This group invitation is already complete".

Earlier, all the expired stamps were shown in the 'unused' column under stamp details. 

2. API to show expiry date of stamps - This API will show the list of stamps which are going to expire. 

This API has two request parameters - 'lookUpPeriod' and 'includeExpired'.

“LookupPeriod” defines the timeframe for checking stamp expiry. The default value of 'lookUpPeriod' is 30, which will show the stamps which will expire in 30 days.

“includeExpired” defines whether you want to get data of stamps which have already expired.  The default value is false, which will exclude the stamps which are already expired.

Documentation: https://docs.leegality.com/v3.1#tag/API-3.1/paths/~1v3.1~1series~1expiry/get

This issue has been resolved now and default set of Reviewer notifications will be triggered when none of Emails are customized for Reviewer. The fix has been deployed on App1.

But in the Audit trail ( of completed document), it showed Stamp value as the Stamp series (series added in the stamp group). 

Suppose a stamp group PB01 has stamp series 01 (denomination 50) and the Stamp value entered was 200. Then in the final document, there were 4 stamp pages but in the Audit trail - the field Stamp value was equal to 50 (instead of 200). 

This issue has now been fixed.

2) Cloud DSC will be referred to as "Offline_Sign" in the APIs due to technical reasons. Appropriate explanations are being added to the documentation for ease of reference. 

3) API 2.1 support for Cloud DSC does not support the option to fix signer ID at the moment.

A confirmation pop-up with message "Are you sure? - Do you want to extend the expiry?" has been added. 

3. Earlier only webhook version 2.1 was supported in the New Document Flow and all versions were supported on the Workflow. 

Now, all webhook versions - 2.1, 2.2 and 2.3 are also supported in the New document flow same as that in the Workflow.

6. There was an issue while loading the template with header and footer. Quite lengthy templates when coupled with the header and footer the document generation failed in the Document creation and signing journey. 

We have optimized the method through which it would be much less time taking. But, if the template has current page number in the header or footer then it might take some time.

CC feature can be enabled for a particular organisation from the Config in Admin panel and then through Account level settings. 

CC feature is currently live for New Document flow on Sandbox.

2. When a document was being created with a stamp group containing expired stamp series, then a non-stamped document was getting created, instead of an error being shown. 

This has been fixed --> an error message will now be visible on the Front End saying "Insufficient stamps in the stamp group to create desired stamp value". 

This check has been added in the New Document flow, Workflow, API 3.0 and API 2.1. 

3. Earlier when hyperlinks were added in the template header or footer, then document generation failed in both sending and signing journey. 

In order to avoid this issue, the hyperlink functionality has been removed from header and footer in both Dashboard and Admin panel. 

4. Earlier the stamp series list had columns - total, reserved, used, unused, blocked, and process. But the expired stamps were not included in any of these columns, making it difficult for the user to figure out the no. of expired stamps. 

Therefore, an Expired column has been added on the stamp series listing screen. This feature was previously added on for Client Dashboard and has now also been added in Admin panel.

The fix has currently been deployed on Kepler (signing journey) and will soon be launched in the Sending journey.

2. Issue that rate of Interest field did not take decimal value. Now, the validation has been changed and can accept decimal values upto 2 decimal places. 

3. The custom consent length has been increased from 500 to 1000 characters. 

4. Few of the labels(Invitee level configs and Signing journey options) in Workflow and New document flow were different. Therefore, to make it alike and more user friendly label changes have been made in Workflow(same as New Document Flow). 

5. Clients faced an issue where users with many sign invitations had to login and logout multiple times. Therefore, in order to avoid login and logout, we have integrated Web SDK in Dashboard. 

When sign/approve button is clicked from Document details page or Document listing page(Received tab), the user will be redirected to a New Tab to complete the signing jouney. Once the signing is completed, the window will automatically close and the parent window data will be refreshed.