Create Signatory Lists and Approvers for signing electronic documents

 

Setting the Scene


You have a contracting workflow application where the assigned number and designated signatories depends on the options selected by the requestor.

This approach presents two key challenges:

  1. Each signatory's name and email fields must be individually configured and referenced in the E-SIGN block.
  2. Due to varying signatory requirements, multiple E-SIGN blocks are needed for different recipient counts and roles. Though functional, this makes the system harder to maintain and update over time.

As a business, you need a solution that allows you to:

  • Maintain a single list of signatory fields rather than managing multiple E-SIGN blocks.
  • Use one E-SIGN block that automatically adjusts to different signatory requirements, reducing complexity and maintenance efforts.

Required Reading
LIST variables are typically used from Merge blocks that have merged the names and emails of e-signature recipients from text input fields in FORM blocks. Learn more about Merge blocks.

If LIST variables are used, the list of the names and emails of e-signature recipients in the Merge block or LIST block must correspond to each other by order and have the same length.

Link: https://support.checkbox.ai/hc/en-us/articles/360024381713-E-SIGN-Block

 

Step-by-step instructions


Set Up Your Contracting App Structure

1. Start by creating the initial framework of your contracting app. This includes setting up FORMs where users can specify the number of signatories and provide their details.

In this example, users should be able to select the required number of signatories and specify which signatures are needed. Additionally, users must manually input the details (e.g., names, email addresses) for each required signatory.

Contract Information FORM.png

Counterparty Information FORM.png

Contracting workflow app.png

2. Return to the Studio and add a MERGE block, then create a route connecting the FORM block (or the last used block) to it.

FORM to MERGE.png

 

Using the MERGE Block to Create a LIST Variable for Signatory Details

The next steps is to use the MERGE block to consolidate your referenced variables into a single OUTPUT LIST.

 

Merging Name variables of the signatories into a Single OUTPUT LIST

1. Click on the MERGE block to edit its properties, then select “+ Add output sets”

Adding an OUTPUT SET.png

2. Define a variable name for the LIST that will store all required signatory names

3. Click "+ Add variable" for each input field capturing signatory names to include them in the LIST, and enter the variable names into each “Variable REF” field.

In this example, we will be adding CounterpartyName, SignatoryName1, and SignatoryName2, as these fields capture the names of the signers in the app.

4. Enter a condition for any variables added to the LIST (if applicable). The conditions will act as filters to determine which items will be included in the LIST output.

For example, if only the counterparty’s signature is required for an agreement, the LIST will only include the value of CounterpartyName.

SignersNameList.png

 

Merging Email Address variables of the signatories into a Single OUTPUT LIST

  1. In the same MERGE block where we created the signer names LIST variable, click "+ Add output sets" to create a new OUTPUT LIST. Define a variable name for this LIST that will store all email addresses of the required signatories.
  2. Click "+ Add variable" for each input field that captures the email address of a signatory, then enter the variable names into each “Variable REF” field.

    In this example, we will add CounterpartyEmail, SignatoryEmail1, and SignatoryEmail2, as these fields capture the signers' email addresses in the app.

  3. 3. Set a condition for each variable (if applicable) to filter which email addresses will be included in the LIST OUTPUT.

    SignersEmailList.png

 

Adding Conditions to the Signature Section of Your DOC GEN Template

Why Add Conditions to the Signature Section?

Conditions in the signature section are important for controlling where each signatory’s signature is placed in the document.

E-SIGN tags are used to mark the signature locations in the document. For example:

  • The first person from the list will sign where the [[signature1_doc1]] tag is placed.
  • The second person will sign where [[signature2_doc1]] is placed, and so on.

Since the required signatories can vary for each agreement, adding conditions ensures that signers are directed to sign in the correct location within the document. (See attached Word document for an example)

 

Setting Up Your E-SIGN Block

1. Return to the Studio and add an E-SIGN block, then create a route connecting it to the REPORT block (or your last used block).

Adding the ESIGN block.png

2. In the E-SIGN block, click "+ Add Recipients".

3. Enter the name list variable in the Name field and the email list variable in the Email field.

4. From the Attached Document dropdown, select the document that requires signatures.

ESIGN block configuration.png

 

Sample Outcomes

1. If the only required signer is the counterparty (ACME Company has pre-signed the document):

    • Despite using a LIST variable for the names and emails of the recipients, the signatory is filtered. In this example, we see that only the counterparty receives the document for signing due to the conditions applied to the reference variables in the output list.
    • As a result of the conditions set in the DOC GEN template, only the counterparty's details and the ACME signatory appear in the document.

Outcome - Counterparty and 1 signer from ACME.png

2. If both the counterparty and one signatory from ACME are required to sign the document:

    • The document is sent to both the counterparty and the designated ACME signatory for signing.
    • Only their details appear in the document, as defined by the conditions in the DOC GEN template.

Outcome - Counterparty and 1 signer from ACME2.png

3. If the counterparty and two signatories from ACME are required to sign the document:

    • The document is sent to the counterparty and the two designated ACME signatories for signing.
    • Their details are displayed in the document based on the conditions and syntax applied in the DOC GEN template.

Outcome - Counterparty and 2 signers from ACME3.png

Note: As a best practice, e-signature tags are typically formatted in white font to remain "invisible" and prevent them from obstructing the signers' signatures.

In the examples above, we intentionally kept the tags visible to illustrate how signers are directed to sign at the locations where the tags are designated in the template.

 

Considerations


With this setup, the document is sent out simultaneously to all signers. This happens because the recipient order specified in the LIST variable is not retained when passed into the E-SIGN block.