How to: Accept User Input to Render Components for E-Signature

This page will walk the user through a complex use case showcasing the Flows, Conditional Logic, and E-Signature

Phase 1: Imagine the Scenario

It is commonplace for an S-Docs User or Admin to generate a large amount of documents on a day to day basis. S-Docs offers various ways to generate multiple documents at once through methods such as button, flows, LWC, or S-Docs Jobs.

Having a large number of documents out in the wild is difficult to deal with on their own. Users would often rather have everything collected in one place to reduce time navigating between documents, records, and more. To handle this scenario, S-Docs evolved to handle batch generation, particularly through flows, which also provides the user the option to combine the created documents into one.

When S-Sign gets thrown into the mix, the use case becomes much more complex, and workflows fall apart. When we think of E-Signature with Sign-In-Person scenarios or sending the contract via email, it is impossible to account for a combined document. So what’s the solution?

Phase 2: The Generalized Workflow

The above diagram showcases the general steps one needs to take to achieve a combined document with different S-Sign Input Fields. The process goes as follows:

1. Gather the template’s you would like to render using a Get Records Component
2. Configure a screen to handle user input
3. For every selection made by the user, add the user input, particularly the value, to the appropriate userInput fields as outlined in Handling User Input
4. Call the Generate Document with Input Invokable

   1. The parent template will need to be of format PDF
   2. The component templates called within the parent are of format Component or Component Type PDF-Upload
5. Finalize with standard E-Signature invocable (prepare envelope, seal envelope, send email

Phase 3: Understanding the Screen Component + Assignment Action

In this example, we use a screen with a Data Table Component to select user input. The options displayed to the user will be added to the Source Collection. Prior to the screen we collect all the templates we would like the user to select from in a Get Records invocable action, setting the data returned to All Records.

We then add a loop to go through the user’s selected choices. This works since the Data Table has a format [DataTable].selectedRows, a collection of all the selected choices. When we move into the assignment, we will add the current value to the userInputField.value.

Phase 4: Understanding the Parent and Component Templates

In the parent template, we can conditionally render each component based on the provided value. In this example we store the name’s from the DataTable.selectedRow, so we look if that name is included in the collection.

As these components are of type PDF-Upload, it is essential that all of the S-Sign Fields are also created at the parent level. If a field is missing, you will encounter an error that the S-Sign Field is not defined.

In the component, we define the S-Sign Field that we are pulling in. The fields from all of the components must be unique as the parent references them all. This means that ff we define S-Sign Fields 1-2 in the first component, 2-6 in the second component, the third component must use fields 7 and on.

While this approach does work, it is not best for scalability. In the case where complex template’s are being used, Governor Limits still apply. It is also time consuming to add S-Sign fields up to the specified amount in both the parent and each individual component. Template Format of type component are preferred as they handle Signer Input’s easier, along with easier reorganizing to handle Dynamic Signers.