Rules of thumb for using datafields

As stated under Creating Concepts, concepts should either be used to:

1. Hosting concept labels — mimic legal terms that would customarily be drafted with a capital (e.g.: “the Purchaser”); and/or

2. Hosting datafields — provide a storage location for datafields (e.g.: the Purchaser’s name, address, company number, etc.).

In order to make concepts and their datafields as relevant as possible in any given situation, the following rules of thumb should be applied:

• Concepts should generally not have more than 15 datafields.

  • If more datafields are required, then concepts should probably be subdivided into a general concept, and a few more specialised but related concepts. The required datafields should then be assigned to the most suitable specialised concepts.

• Concepts are intended to foster re-use of datafields across different documents. Highly specific concepts for which the likelihood of re-use is limited (e.g., because the datafields are only relevant for a specific customer, or even for a specific contract) should thus be separated from more generic concepts that can be reused across documents.

• Do not think about concepts as only mimicking defined legal terms that are customarily drafted with a capital. It is perfectly fine if a concept is never used as such, and only used as a storage location for datafields (e.g.: an employment agreement will rarely refer to an employee’s salary as “the Salary” but the salary amount is nonetheless crucial to include in such a contract).

• You are strongly advised to create a logical order for the datafields (which you can change using the buttons), to ensure that datafields that are frequently filled in together, will be displayed together in the data-dashboard of Assemble Document.

• Once you are up and running and creating multiple concepts, you may want to read more on how to organise your concepts.

• You should always select the most appropriate datafield type, because the operations you can do with a datafield further down the road, will depend on it.

For example, while you could select a text field to hold the commencement date, doing so will require your users to actually type in a date (with the risk of possible variations — one user would perhaps type in “1st Sept 2018”, while another may type in “01-09-2018”).

If you would select a date field instead, then users will get a nice calendar popup from which they can choose. More importantly, with an actual date field, you will be able to perform calculations, such as adding or subtracting months or years in order to arrive at the termination date.

None of these calculations are possible if you would have selected a text field, because — from a computer’s perspective — a text such as “1st Sept 2018” is just a bunch of letters in which we human beings happen to see meaning.

• Assign labels to datafields, because this can help end-users understand what the datafield is for, and also facilitates easier use of the datafields within the Q&A editor. See the short video below.