Creating signature blocks

Drafting an agreement — or sometimes other types of documents — means that, somewhere in the document, you will have to add a signature block. There should be at least as many signature blocks as there are parties, containing their names and titles. How to go about this?

Let’s go over a step-by-step example. We will be making a signature block for a lease agreement between two parties (legal entities), each being represented by max. two persons (who may be acting in various capacities). We will be working in the Assemble Document mode for the purposes of this How To.

The video above is a more basic introduction to signature blocks and therefore does not follow the structure of the article below.

Setting up the structure

Create a new library clause by clicking the button and selecting New library clause. First we must decide how to structure our signature block. Signature blocks are usually structured as two separate blocks next to each other (either for two parties or for two representatives of some party). There should be some space for the actual signature to go. That’s why a table seems to be the most appropriate way of structuring the signature block. Let’s set up a basic table.

We need at least 4 rows (name of the party, space for the signature, name of the representative and his/her title) and 2 columns (one for each representative). Following the rules of making tables in the ClauseBase grammar, that would look as follows:

|| || ||
|| || ||
|| || ||
|| || ||

Any new clause will contain a paragraph number already (“1.”). If a clause contains only a table, this number has to be removed. A table on itself cannot be a numbered paragraph — it can, however, be part of a numbered paragraph or clause if text is added before the table and an empty line is left between the text and the table.

Adding details of the parties

Our signature block must contain the following information:

• the name of each representative

• the title / capacity of each representative

In normal circumstances, you would have already made the concepts and datafields implementing the parties and their information. For the purposes of this tutorial however, we will do it from scratch. If you are familiar with creating concepts and datafields, please skip ahead to Populating the table.

Creating concepts and datafields

Creating a concept & concept label

Concepts can be created in various ways. We will be creating them from inside the Assemble Document mode. The first party signing our agreement will be the lessor, so let’s create a concept for the lessor by typing #Lessor in the top left cell. If this concept does not exist yet, you will be shown a red alert underneath the clause editor:

Click on #lessor and select create a new Concept.

Now we have to choose a location for our concept. Typically this would be a special concepts folder (which can be created by holding Shift and clicking ) in the appropriate place in your clause library. Browse to the location of your choosing and click select current folder. A new tab will now be opened in our editor to complete the properties of our newly created concept “lessor”. Navigate to the concept labels property of the concept (in the navigation menu on the right).

Add an English concept-label by clicking the button. Singular will be “lessor” and plural “lessors”. Choose “neutral” for the gender. The other options are fine: a defined article (“the”) must be used, by default this concept label should be singular and its capitalization may be adapted to the applicable grammar & styling.

Adding datafields

While still in the concept editor, navigate to datafields in the menu on the right. We need four different datafields: one for each representative’s name and one for each representative’s capacity. As these are textual inputs, we will choose text type datafields.

Click the button and select text. Give your datafield a name, e.g. representative1-name. Repeat this for each of the four datafields (representative1-name, representative1-title, representative2-name and representative2-title).

Hit the save in library button in the bottom left corner.

Populating the table

Our table is still mostly empty for now, so let’s start giving it some actual content. The first row already contains #Lessor.

Capitalising the first letter of #Lessor makes sure that any article being added in front of it will be capitalised. That is why capitalising a reference to a concept should only be done in the beginning of a sentence (or in any other case where you would want the first letter of the article to be capitalised as well).

The third and fourth rows should contain the names and capacities of the representatives of the Lessor. The #lessor concept should already contain the relevant datafields (if this is not yet the case, please follow the instructions in Adding datafields). Add these datafields to the relevant cell by appending the name of the datafield behind #lessor and adding a ^ symbol in between. Our table will now look like this:

|| #Lessor                              ||                                      ||
||                                      ||                                      ||
|| Name: #lessor^representative1-name   || Name: #lessor^representative2-name   ||
|| Title: #lessor^representative1-title || Title: #lessor^representative2-title ||

Tip: when creating a table, the text can start looking messy. However, ClauseBase has a feature to make your source text more easily viewable. Click the three dots in the top right corner of the clause editor and choose reformat tables. Now your source text will be reformatted to look more like the actual table.

Having added the datafields, any user can complete the details of both representatives in the table.

But there are undoubtedly cases where the Lessor will be represented by only one representative (e.g. in case of a power of attorney granted to one person). How can we avoid having a placeholder in our text if the details of only one representative have been completed?

We can do this by adding a condition to the details of our second representative. In this case, we want the second column of our table not to be shown unless the name of the second representative has been completed. To achieve this, we will make use of the @assigned special function. This function will evaluate whether a datafield was assigned a value or not and will on that basis return true or false.

To make our column conditional, we have to add an additional row on top of our table, which contains the condition for a column to be shown in the relevant column.

A condition in ClauseBase is always written between curly brackets ({ }). The condition we will be using is: if #lessor^representative2-name was assigned a value, only then the column should be shown. In ClauseBase grammar, the cell on top of the column would then look as follows: {@assigned(#lessor^representative2-name)}. Technically, @assigned will return “true” if #lessor^representative2-name was assigned a value and “false” if it wasn’t. If the condition evaluates to false, the column will not be shown. Adding this to our table (and reformatting it) results in the following:

||                                      || {@assigned(#lessor^representative2-name)} ||
|| #Lessor                              ||                                           ||
||                                      ||                                           ||
|| Name: #lessor^representative1-name   || Name: #lessor^representative2-name        ||
|| Title: #lessor^representative1-title || Title: #lessor^representative2-title      ||

Adding space for the signatures

Now our table contains an empty row where the signatures should go. However, we need an indicator where each representative should sign.

We can make use of the % signature % functionality included in ClauseBase. Typing % signature % in both cells of the third row. This will make sure a dotted line is inserted, with sufficient space above and below the line for a (large) signature. Check out the article on Special codes for more information.

||                                      || {@assigned(#lessor^representative2-name)} ||
|| #Lessor                              ||                                           ||
|| % signature %                        || % signature %                             ||
|| Name: #lessor^representative1-name   || Name: #lessor^representative2-name        ||
|| Title: #lessor^representative1-title || Title: #lessor^representative2-title      ||

Alternatively, you could make use of the @tab-u special function in the third row to create a full line instead of a dotted line.

Formatting the table

Now that the content of our table is ready, let’s make sure it looks good as well. For the purposes of our tutorial, we want a table that is aligned to the left, with the name of the party in all caps and bold and without any borders.

Adding styling to a table can be done either by modifying the custom styling of the clause containing the table or by adding deviating styling to our table itself. We will go with the second option in this tutorial.

To do this, we need to add a new row with one single cell on top of our table. This cell will contain our styling settings for the entire table, each separated by a comma, as follows: || % align left, borders false, borders horizontal false, borders vertical false % ||.

Next we add the bold and all caps deviating styling to our (now) third row between % symbols: % bold true, all caps %. The entire table should now look as follows:

|| % align left, borders false, borders horizontal false, borders vertical false % ||
||                                      || {@assigned(#lessor^representative2-name)} ||
|| % bold true, all caps % #Lessor      ||                                           ||
|| % signature %                        || % signature %                             ||
|| Name: #lessor^representative1-name   || Name: #lessor^representative2-name        ||
|| Title: #lessor^representative1-title || Title: #lessor^representative2-title      ||

Finishing your work

The signature block for the Lessor is now complete. Duplicating it for the Lessee should now be easy: just copy/paste your Lessor table and replace the #lessor concept by #lessee, after having created the relevant datafields.

For a more advanced exercise, you can try to make the signature block repeat itself. This can be handy in case it is possible the agreement will be entered into between multiple lessors and/or lessees.

First, replace all text datafields for the names of the lessors/lessees, their representatives and the capacities of their representatives by repeating list type datafields of type text. This will make sure the input can be different between the various repeating instances of your signature blocks. In addition, instead of only referring to the concept label of #lessor or #lessee, the signature block should probably now also refer to the individual name of the relevant lessor/lessee to make sure on whose behalf the agreement is being signed.

After having done so, select your clause and click the advanced tab in the operations panel. Under repeat clause, choose a datafield on the basis of which the clause should repeat itself (e.g. the repeating list datafield containing the names of the lessors/lessees). If done correctly, the signature block should now be repeated for as many times as there are inputs assigned to the datafield of your choosing.