Build Templates With A Dynamic Number of Signers

639 0 1 November 9, 2022

Tags: , , ,

Introduction

S-Sign allows you to easily send e-signature requests that require multiple signers by building out multiple signer profiles in a template. However, it's not always practical to rely on a fixed number of signer profiles. Sometimes a document might require only one signer, while other times it might require five. Maybe a document always needs to be signed by every contact role related to an opportunity. In these situations, it's not efficient to constantly edit the number of signer profiles for a template.

Luckily, S-Sign allows you to set a dynamic number of signer profiles and signature inputs for a document. There are two primary ways to do this:

  1. Using the Conditional Logic Feature
  2. Using Related Lists

Using the Conditional Logic Feature

The S-Docs Conditional Logic Feature allows you to conditionally show or hide portions of your documents based on conditions that you define, but it can also be used to conditionally render S-Sign elements, like specific signer profiles and different S-Sign input field types. Using the render feature, you can set up s-sign templates that include a different number of signers and input fields based on certain predefined conditions.

In the following example, we've written our render statement so that Signer 2's signer profile (and corresponding signature input field) will only get created if the Opportunity that this document is generated from has its stage field set to Closed.

<!--RENDER='{{!Opportunity.StageName}}' == 'Closed' -->
[[SSIGN_PROFILE Email='signer2@example.com' ProfileName='Signer 2' RoutingPosition='2']]
[[SSIGN_INPUT Profile='Signer 2' Type='Signature']]
<!--ENDRENDER-->

As you can see, using the conditional logic feature to set dynamic signer profiles requires you to write out your S-Sign elements, rather than set them in the S-Sign Template Settings menu. You can use the following attributes in your render statements, which are equivalent to the elements that you can set in the S-Sign Template Settings.

S-Sign Profile Attributes:

  • ProfileName
  • Email
  • RoutingPosition
  • DenyAudit
  • DenyConfirmation
  • SignerName
  • PrevSignerProvidesThisSignersEmail
  • denyConfirmationEmail (None, Partial, Complete, or Both)
Note: These attributes must be preceded by SSIGN_PROFILE, and the entire statement must be enclosed in double square brackets. For example: [[SSIGN_PROFILE Email='signer2@example.com']]

S-Sign Input Field Attributes:

  • Type
  • Profile
  • Required (Type='Text', Type='Checkbox', and Type='Date' only)
  • WriteTo (Type='Text' and Type='Date' only)
  • TextDefault (Type='Text' only)
  • Disabled (Type='Date' only)
  • DateFormat (Type='Date' only)
Note: These attributes must be preceded by SSIGN_INPUT, and the entire statement must be enclosed in double square brackets. For example: [[SSIGN_INPUT Profile='Signer 2' Type='Signature']]

Using Related Lists

You can also dynamically generate signer profiles and input fields using related list data (LineItems and LineItemsSOQL). This is useful if you need to generate S-Sign requests that automatically include signer profiles and input fields for each contact role related to a specific record.

In the following example, let's assume you have a contract that needs to be signed by each opportunity contact role and each account contact role related to your opportunity. Let's also assume that all opportunity contact roles need to sign before any account contact roles sign. Using LineItemsSOQL statements, S-Sign can easily accomplish this. For each object (opportunity and account), we'll create 2 LineItemsSOQL statements: one to generate signer profiles, and another to generate S-Sign input fields.

<!--{{!
<lineitemsSOQL>
<class>none</class>
<listname>opportunitycontactrole</listname>
<column prefix="[[SSIGN_PROFILE Email='" postfix="' ">Contact.email</column>
<column prefix="RoutingPosition='1" postfix="' ">rownum</column>
<column prefix="ProfileName='Signer C" postfix="']]">rownum</column>
<where>Opportunity.Id='{{!Opportunity.Id}}'</where>
</lineitemsSOQL>
}}-->
<!--{{!
<lineitemsSOQL>
<class>table239</class>
<listname>opportunitycontactrole</listname>
<column>Contact.Name</column>
<column prefix="<br /><div style='width:20pt;'>[[SSIGN_INPUT Type='Signature' Profile='Signer C" postfix="']]</div>">rownum</column>
<where>Opportunity.Id='{{!Opportunity.Id}}'</where>
</lineitemsSOQL>
}}-->
<!--{{!
<lineitemsSOQL>
<class>none</class>
<listname>accountcontactrole</listname>
<column prefix="[[SSIGN_PROFILE Email='" postfix="' ">Contact.email</column>
<column prefix="RoutingPosition='2" postfix="' ">rownum</column>
<column prefix="ProfileName='Signer A" postfix="']]">rownum</column>
<where>Opportunity.Id='{{!Opportunity.Id}}'</where>
</lineitemsSOQL>
}}-->
<!--{{!
<lineitemsSOQL>
<class>table239</class>
<listname>accountcontactrole</listname>
<column>Contact.Name</column>
<column prefix="<br /><div style='width:20pt;'>[[SSIGN_INPUT Type='Signature' Profile='Signer A" postfix="']]</div>">rownum</column>
<where>Opportunity.Id='{{!Opportunity.Id}}'</where>
</lineitemsSOQL>
}}-->

When you use the code listed above, each opportunity contact role will be designated an incrementing signer profile name starting at Signer C1, and each account contract role will be designated an incrementing signer profile name starting at Signer A1. Additionally, all opportunity contact roles will sign before any account contact roles sign because of how we set the RoutingPosition attribute. In this example, a signature input will be generated for each contact role, but you can customize this code to generate any number of different s-sign inputs.

Tags: , , ,

Was this helpful?