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 Render Feature
  2. Using Related Lists

Using the Render Feature

The S-Docs Render 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.

As you can see, using the render 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
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.

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.