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

### Phase 1: Imagine the Scenario <a href="#phase-1-imagine-the-scenario" id="phase-1-imagine-the-scenario"></a>

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 <a href="#phase-2-the-generalized-workflow" id="phase-2-the-generalized-workflow"></a>

<figure><img src="/files/KpWSwIEGofkcYTMmDOKz" alt=""><figcaption></figcaption></figure>

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](https://sdoc.atlassian.net/wiki/spaces/SDOCS/pages/1927741457/User+Input+Tutorial?search_id=ac927062-5498-48c1-a003-1258641b27b4)
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 <a href="#phase-3-understanding-the-screen-component--assignment-action" id="phase-3-understanding-the-screen-component--assignment-action"></a>

<figure><img src="/files/rO1fyiJRKzWKxuV1F5dv" alt=""><figcaption></figcaption></figure>

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**.

<figure><img src="/files/FLVI7ePckdf6fshNQtdj" alt=""><figcaption></figcaption></figure>

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 <a href="#phase-4-understanding-the-parent-and-component-templates" id="phase-4-understanding-the-parent-and-component-templates"></a>

<figure><img src="/files/yxyWPmxkuUCrcNmAK3X1" alt=""><figcaption></figcaption></figure>

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.

<figure><img src="/files/8iNZhdes5RxhCr2zAf70" alt=""><figcaption></figcaption></figure>

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.

{% hint style="warning" %}
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.
{% endhint %}

&#x20;

&#x20;


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://help.sdocs.com/s-sign/template-configuration-fields-profiles-settings/how-to-accept-user-input-to-render-components-for-e-signature.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.