Ever wanted to have a user fill out a form whenever they generate a document? Maybe even form that allows you to collect the user's answers as merge fields and use them in your template as you would any other merge field? Wouldn't it be great if something like that existed?

Well, great news: the Runtime Prompts feature does just that!

Setting up a template with Runtime Prompts is fairly simple: open your template in the template editor, head over to the Runtime Prompts tab, and start defining some prompts to collect from the user at runtime.

We've created a great example you can play around with in case you want to dive into the Runtime Prompts feature head-first: the Boiler Inspection Follow-up Letter found in our Template Library. You can import this entire template into your own org in a matter of seconds, Runtime Prompts and all. You can click here to download the Boiler Inspection Follow-up Letter and click here to learn how to import this template into S-Docs.

This template leverages the Runtime Prompts feature and the RENDER feature in order to create a dynamic document whose output varies based on input gathered from the user immediately prior to document generation. In other words, when the user decides to generate this document, they will be prompted to fill out a form, and the answers provided in this form are used in the template as merge fields. This is the case for any template leveraging the Runtime Prompts feature.

More specifically, when a user decides to generate this document, that user will be prompted to select from a list of boiler parts that need to be replaced. Once the user makes their selection, the selected parts are merged into the final document as a bullet-delimited list. Additionally, whenever the user generates this document, the user will be prompted for a return date (if applicable) and whether the customer has decided to repair the boiler themselves; depending on the values provided, certain sections will appear. For example, if the user confirms that the customer has decided to self repair, the final document will include a recommendation for a home repair guide intended for customers who've opted to repair their boiler themselves.

For those who prefer a more formal approach when learning a new topic, we'll provide the textbook explanation below.

Each piece of input you'd like to collect is referred to as a "Prompt". You can create as many Prompts as you'd like; click "Add Another Prompt" at the bottom of the screen to add a new Prompt. The form opportunities are limitless!

Each Prompt allows you to define the name of the merge field that will contain that user's response to the Prompt.

You can specify whether a Prompt is "Required" - this means that the user will not be allowed to generate the document if that field is left blank. On the flipside, you can forgo making a field "Required" and specify a "Default Value" as the "data" for your Prompt's merge field if the user doesn't answer that particular prompt. Or you can leave "Required" unchecked and "Default value" blank and simply allow the user to leave their answer to that Prompt blank.

Now, what kinds of Prompts are there? We have three basic types: Text, Date, and Checkbox.

Text and Date Prompts are pretty simple. A Text Prompt just a simple free-form text field that the user can type whatever they want into.

Date Prompts provide a date picker at runtime that the user can enter a date into. This date can be formatted with format-date(e.g. {{!MyDate MM/dd/yyyy}}), or it can be used to filter a WHERE clause in your related list (e.g. WHERE CreatedDate > {!MyDate}), or it can do pretty much anything else an ordinary date merge field can do.

Checkbox Prompts are a bit more complicated. You can provide several different pre-defined values for the user to select from; we refer to each of these values as an "Option". An Option can be just one word, or it can consist of heavily formatted rich text paragraphs. You can also use merge fields in an Option. For a single Checkbox Prompt, you can define as many Options as you'd like; you can add and remove Options via the "Add Another Option" and "Remove Last Option" buttons found at the bottom of that Checkbox Prompt's list of Options.

Checkbox Prompts have a few different parameters compared to Text and Date Prompts. When the user checks off a few options, they are combined together and can be referenced by the single merge field you defined for the Checkbox Prompt. You can optionally specify a delimiter, which is what separates each Option if the user selects multiple options. For example, say you have Options "Okay", "Good", "Better", & "Best", your merge field is {{!MyCheckboxPrompt}}, and your delimiter is "AND": if the user selects "Good", "Better", and "Best" at runtime, then {{!MyCheckboxPrompt}} will be replaced with "Okay AND Good AND Best" in the final document.

For a given Checkbox Prompt, you can also specify the minimum and maximum number of Options that can be selected by the user. Note that these fields are required.

Now, what about picklists? Where are the Picklist Prompts!? Trick question, they're here: Runtime Prompts plays off of simplicity and flexibility to allow you to get a lot of power out of these three little Prompt types.

So, how can we get a picklist? Well, let's start with what a picklist functionally is: a collection of options that allows for the selection of exactly one of those options. In other words, a list of options from which you can select a minimum of 1 option and maximum of 1 option, meaning we can simply create a Checkbox Prompt with "1" as the value for both "Minimum number of options that can be selected" and "Maximum number of options that can be selected".

That's it! We designed Runtime Prompts to be as simple as possible while providing enough flexibility so that you can integrate it with other features in order to achieve pretty much any result imaginable when form input is required prior to document generation. For example, the example template described at the beginning of this article uses Runtime Prompt merge fields alongside the RENDER feature to conditionally render sections of the template based on info provided by the user immediately prior to document generation. This is one of many examples of how we can use form data to build a living, breathing document.