Creating a list with both predefined options and free input
Last updated
Last updated
One or more clauses in your document will contain lists that have some predefined options but allow for user input as well. In many cases, as a template creator you may not be able to provide for all options exhaustively. There may, therefore, be a need for users to choose both from a predefined list of options as well as have the option to provide his/her own input. How would you create such a clause in Clause9?
To avoid cluttering your production account, it is advisable following these steps in your Clause9 Sandbox account. If you do not have such Sandbox account, please contact your administrator.
Let’s take a conditions precedent clause in a loan agreement as an example. Typically there are a number of conditions precedent (abbreviated to “CPs” for ease of reference) that will be included in any deal, such as (i) corporate documents approving the transaction, (ii) validly executed security documents and (iii) legal opinions. We will be creating a mockup conditions precedent clause with each of these predefined CPs as well as the option for a user to provide additional CPs freely. We will be implementing the following basic clause:
For the remainder of this tutorial, you will need the following concepts:
#lender, with concept label “lender”
#borrower, with concept label “borrower”
#loan-agreement, with concept label “loan agreement”
#finance-document, with concept label “finance document”
#security-document, with concept label “security document”
Create a new clause. Under content title in the navigation menu on the right, enter “Conditions precedent” as the title of our clause. Head to content body.
The main paragraph of the clause requires the use of the concept #lender in its possessive form. In Clause9 grammar, this can be implemented simply by appending 's to the concept reference.
In addition, the reference to “this Loan Agreement” is easy to implement in Clause9 grammar: after the hashtag, enter a degree symbol ° as follows: #°loan-agreement. The initial paragraph will then look as follows:
Our next challenge is making sure our list both caters for the predefined options and the free input. The obvious way to make a list is by using a combination of:
the list of texts type datafield to enable the user to choose multiple options, and
a form of enumeration that forces use of a bulleted list.
The bulleted enumeration can be created in three ways:
by using the {AND! | alpha | beta | gamma} grammar. The use of the exclamation mark forces Clause9 to make a bulleted list of the three elements alpha, beta and gamma.
by using * AND grammar, followed by individual bullets preceded by an asterisk *.
by using (a variation of) the @bullets special function.
Check out the documentation of both options for our list. Before clicking to the next page, consider for a moment how you would go about creating our list.
To be able to create our list with predefines, we will need to make use of the * AND grammar. Why is this the case?
When the user chooses an option, Clause9 must enable some text (i.e. the actual plain text containing the CP language) based on this option. These options will be implemented as predefines inside of a list of texts type datafield. This way we can make the text of each bullet (each asterisk in our grammar) conditional on the relevant predefine being selected.
Technically we could reach the same result with the {AND! | … | …} grammar. Further on in this tutorial, however, we will discover why this is not the ideal solution.
As mentioned above, we want our end user to be able to select CPs from a predefined list which will be implemented in Clause9 making use of a “list of texts” type datafield. Create such datafield called conditions-precedent in the concept #loan-agreement.
If you are working in the Assemble Document mode, you don’t have to switch to the Browse Files mode to edit concepts (or other file types). A quicker way to edit a concept is to open it by double clicking on that concept in the list below your clause editor.
We want to assign a predefine for each option, i.e. for each CP. Let’s create three predefines for the conditions-precedent datafield:
corporate-docs for the board resolution CP
security-docs for the executed security document CP
legal-opinion for the final legal opinion CP
Leave only the predefined values can be stored (no free values) unchecked for now.
Having made the predefines, we can continue writing our clause grammar. Each subparagraph should be subject to the condition that the relevant predefine was included in the datafield #loan-agreement^conditions-precedent. In Clause9 grammar, this looks as follows: {"predefine" in #loan-agreement^conditions-precedent: text that should be shown}.
Note that the grammar for writing conditions is different for the text type datafield and the list of texts type datafield. This is due to the fact that the latter type may contain more than one input, while the text type datafield can only contain one input.
Implementing this for our CP predefines, the grammar will look like this:
Before starting work on the possibility for free input of new CPs, we will be looking at ways of fine-tuning our clause grammar to make sure it will adapt to various different contexts.
Our clause grammar looks like this at the moment:
Reading through this, you will note that the concepts #security-document and #finance-document are singular (unless you have changed this setting when creating the concept labels), but our text refers to them as if they were plural. For example in the legal opinion CP, the text says “that the Finance Document are binding upon the Borrower” as our original text assumed that there was more than one Finance Document.
Clause9 offers you the possibility to adapt this text automatically to the context of the agreement: whether there is more than one Finance Document or Security Document. We do this by adding some additional grammar, i.e. by surrounding both the words that should change and the word on the basis of which they should change with “greater than” and “less than” symbols: <>.
As there are two concepts on the basis of which the text should be changed, we should give Clause9 some tips on the basis of which it can determine which change to make. This is done by including the concept on the basis of which the change should be made between the <> symbols as follows: <text: concept-reference>. Implementing this for our specific grammar, we get the following result:
Some words have multiple meanings in a language. In our language, this is the case for the word “copies”. “Copies” can be both a verb and a noun. However to be able to make the right changes, Clause9 must know which type of word “copies” is.
There is an easy way to see whether there is an ambiguity like this in your clause: the affected word will be shown in red. By clicking on the word, you can choose between the relevant options:
Choose the noun option. Now our text will adapt automatically to whether #finance-document and #security-document are being used in singular or in plural form.
Finally, let’s finish our clause by building a way for the end user to add his/her own CPs.
So far, we have created a clause that works perfectly with our 3 predefined options. However, we wanted to give an additional option to provide additional CPs as bullets in this same list.
One obvious solution would be to use the existing datafield (#loan-agreement^conditions-precedent) to provide for additional input. This would be implemented be just adding a reference to that datafield as the final bullet, i.e.:
Implement this in your clause and save it. As you input values into your datafield (including the predefines), it will be immediately clear why this doesn’t work. The final bullet contains all inputs to the datafield, including the predefines that already triggered the conditional bullets above.
In view of the above, we have to use a separate datafield. Let’s create one (list of texts type) named conditions-precedent-free. We won’t be adding any predefines to this datafield.
Should we now just add this datafield as a separate, final bullet? No. A similar problem would occur: the final bullet would just contain a comma-separated list instead of adding separate bullets.
Here we can make use of another enumeration option that we listed initially: the @bullets special function. This function make a bulleted list of the inputs of the datafield that it contains. So as our final bullet, we add: * @bullets(#loan-agreement^conditions-precedent-free). Our final clause grammar looks like this:
Any inputs added to #loan-agreement^conditions-precedent-free will be added as separate bullets on the same level as our predefined bullets.
As discussed above, one of the options for creating bulleted lists is using {AND! | alpha | beta} grammar, with alpha and beta being forced into separate bullets.
This option will work for our predefined options, where we would include the CPs subject to their relevant conditions as elements, e.g.: {AND! | {"corporate-docs" in #loan-agreement^conditions-precedent: a resolution of the board of directors of #borrower approving the transactions contemplated by #finance-document} | ...}.
However, we would not be able to add our free input option. If we include @bullets(#loan-agreement^conditions-precedent-free) as the final element, Clause9 will include the inputs to this datafield as a separate bulleted list on the next level, i.e. as sub-bullets to the final element of the original list. This is obviously not how we want to implement the additional CPs.
We also did not write {AND! | #loan-agreement^conditions-precedent-free} to implement the free input option. Consider for a moment what that would look like.
Using the {AND | … | …} grammar, each element must be separated by a pipe symbol |. Therefore Clause9 would interpret the inputs to the list of texts datafield as one single bullet. The result would be one bullet with the inputs to the datafield included as a comma-separated list.
