# Welcome!
Getting started/files/C65XynMFEwqQN6NxGtPY/pages/E5xhDfvmcttN3pOnCsPf
Assemble Document/files/96LPDt6f6gjPc41I9IEr/pages/vZrfHzTDK4DdtbEzE3yK
Drafting clauses/files/PuaOO65JzFolnYAQMtY7/pages/DFWsgSujmXaoPABDiMuP
Using concepts/files/06tJFpiEH67vsgnfIVDN/pages/GLsmn5DlfZzFYr6x22l7
Datafields/files/HMLMAOqh8a5V98qiRJuW/pages/riaeyAJFzQZabaTHUYzy
Organising files/files/eLWvEqmrEK0GdOLpF0oF/pages/K4sEVTLFbtnjQY8VK1xJ
Creating questionnaires/files/ZaksL9Po8wDW4iz7Di1T/pages/l7hb0zDUqp4hsrOb6qmP
Administration/files/EHobzpO9DcBhxlEnHfG2/pages/AOll1eRch8YMGp3dAERH
Styling/files/5faKiSwCWidjmecQlFim/pages/R4UABcKRhn0exXEAmKMI
Integrations/files/1KCbpgQjPsoY6bocpEHu/pages/QVWPjmzLP6HAnzyu4zjw
Special functions/files/iWR78gV1etmo7ifdseqv/pages/C84PovVVP9tdT4jkUvPj
API/files/hnteIiTkwBMvR8qwKoez/pages/BcVisGB1jDPnAInnTmwZ
# What is Clause9? Clause9 is an advanced legal document drafting platform designed to improve the contract drafting process. Clause9 rests on three pillars: 1. Improving your organisation’s contract drafting **knowledge management** by centrally storing intelligent clauses and templates in a library. 2. Increasing **contract drafting efficiency** by quickly stacking intelligent clauses on top of each other while Clause9 takes care of all the clean-up work. 3. **Outsourcing contract creation** via template questionnaires. When you start working with Clause9, you first need to upload clauses to the platform. You can do this individually per clause, or by importing them from a Microsoft Word document. At that stage, you can choose the desired level of intelligence you wish to add to the clauses. Examples include: * Creating defined terminology and setting up cross-references via [concepts](/concepts/introduction-to-concepts) * Indicating [variable fields of information](/datafields/introduction-to-datafields) * Adding [conditions](/clauses/writing-conditions) * Introducing grammatical flexibility * And much more! If this is your first time working with Clause9, we suggest you head over to the [Tutorials website](https://tutorials.clause9.com/) where you can find the tutorials specifically tailored to the user profile your organisation has chosen for you. # Structuring your clause library There are three levels to Clause9 clause libraries: * an **organisation-wide library** that is accessible to every user of the customer’s company / law firm, even if some users may not have editing rights * a **group-based library** for, for example, different departments or cross-departmental practice groups that can only be seen and accessed by members of the group * a **private library** that is only accessible to an individual user Deciding how to structure your clause libraries and where to put your clauses is a strategy that will have to be decided at administrator-level. The following is a list of important questions that need to be asked at the outset in that regard: * Is it your intention to make certain clauses available and **usable across the entire organisation**? Or will you be creating separate silos for different departments? (See also the [FAQ on the viability of such wide sharing](/clauses/clauses-faq#can-the-same-clause-be-used-throughout-my-organisation)). * Who will have the responsibility to vet clauses that enter the organisation-wide library or group-wide library? * Who will be given which access rights? Can everyone access and edit? Or are editing rights limited to a group of more experienced users? It is important to assign the proper roles to the right people so that the entire organisation is aligned on how to use Clause9. # Structuring your clauses An important factor is how to shape the content of your clauses. This consideration essentially comes down to the question whether you will primarily use the Q\&A mode or the Assemble Document mode for the document. If you are primarily using Q\&A mode to highly autom~~a~~te several key documents that are used by business users, it is generally good practice to provide a high level of intelligence for individual clauses in the form of clause- and text enabling conditions so that you can switch between alternative clauses and sentences at the click of a button. Since the focus for your organisation is more on the (business) users using your questionnaires, only the advanced users maintaining and updating the clauses need to be able to interact with the clauses “under the hood”. If the emphasis of your organisation’s use of Clause9 is on Assemble Document mode, then you should focus on creating and structuring clauses in a way that they are very easy to interact with. This means limiting the amount of interactions you can do with a given clause, as normal users will typically assume that, when inserting a clause, what they see is what they get. You may also want to prioritise assignment of attributes more than you would under the Q\&A approach, as more users are working with the individual clauses. For example: say you want to create two alternatives of a pricing clause: one needs to just show the price of the product, the other needs to state that the price is listed in an annex to the contract. The text of the clause listing the price could be: {% code overflow="wrap" %} ``` The Product shall be priced at [insert price here]. ``` {% endcode %} The text of the clause referring to the pricing annex could then be: {% code overflow="wrap" %} ``` The price for the Product shall be as established in the price list as attached to this Contract. ``` {% endcode %} With the Q\&A-focused approach, you would want to put the two sentences in the same clause, separated by a condition that triggers one sentence or the other. Without going into too much detail on the Clause9 grammar just yet, conceptually, that could look something like this: If the answer to the question “where is the product price listed?” equals “contract”, show the following sentence: *The Product shall be priced at \[insert price here].* If the answer to the question “where is the product price listed?” equals “annex”, show the following sentence: *The price for the Product shall be as established in the price list as attached to this Contract.* In the Assemble Document-focused approach, you would want to make two separate clauses and link them together as alternatives using the “links” functionality that each clause has. This allows users to quickly switch between available alternatives at the click of a button. # Drafting modes in Clause9 ## Document assembly mode vs. Q\&A mode Clause9 offers two different modes to create legal documents. Typically you will first start in the document assembly mode (*Assemble Document* menu), where you will either start from scratch or from an existing template, interactively stacking and swapping building blocks, changing data and changing legal terminology to arrive at a new document. The second mode (the Q\&A mode) builds on the document created in the first mode, and presents a list of interactive questions to users. Using the answers given by the users, the underlying document is then interactively filled and modified where necessary. Due to the deliberate constraints imposed by the questions & answers, interactive templates built using the Q\&A mode can allow anyone — even users completely unfamiliar with the legal domain — to quickly create a document in an environment that offers legal guidance through user-friendly questions & answers. {% hint style="info" %} If you are wondering why both modes are split: this increases flexibility, as opposed to the (admittedly simpler) situation of having only one integrated mode. * Not every document requires a questionnaire. Some documents will, for example, be used as subdocuments (e.g., schedules / annexes) of some main document, and will not require their own questionnaire. It may also be the case that the document will be created through server-to-server interactions, i.e. by using Clause9's so-called API — e.g., a law firm that would generate thousands of dynamically composed documents in the context of a mass litigation defence. * Multiple questionnaires can be built for one document, e.g. one simple questionnaire with just a few questions, and one advanced questionnaire with detailed questions for experts. Similarly, you may want to crate different questionnaires for very different products of a company, that all require different changes to be made to the standard sales agreement. * A minority of advanced users like to work exclusively within *Assemble document*, never creating a questionnaire. This has the advantage that you are not constrained by the questionnaire's predefined questions & answers; it has the disadvantage that you need to be sufficiently familiar with the contents of the document, because you will lose all the "guardrails" offered by the questionnaire. \ \ In a certain way, you can see the *Assemble document* mode as the "raw" mode (more flexibility, but with no guidance) and the Q\&A mode as the "polished" mode (less flexibility, but neatly packaged). {% endhint %} ## Workflow overview While the Q\&A mode and the document assembly mode are separate modes, they are strongly connected with each other. As explained above, you build a questionnaire on top of a document created earlier in the document assembly mode. However, the other way around is also possible: you can send a document created in the Q\&A mode to the document assembly mode. For example, once a business user has provided answers, legal experts can also transfer the filled-in template back to the document assembly mode, to apply further customisations that were not allowed in the constrained Q\&A mode. ## In practice: transfer from Assemble Document to Design Q\&A In order to create a questionnaire, you therefore first need to open a saved document or binder, click on the menu at the right side of the screen, and choose the *Send to Q\&A* command.
The document or binder will then be transferred to a new questionnaire, and this questionnaire will be opened in the *Design Q\&A* mode. You will notice that the main menu at the top of the screen will change accordingly. ## **In practice: transfer from a Q\&A to Assemble Document** When you have completed a questionnaire and saved its answers, you can click on the menu at the right side and choose *Open as editable document*.
The questionnaire's document will then be transferred to the *Assemble document* mode, where you can change it however you like. Or even send that modified document once again to the *Design Q\&A* mode to create a new questionnaire. # Creating a questionnaire ## Transfer from Assemble Document A questionnaire ("Q\&A") is an optional, additional layer on top of an existing document or binder. In order to create a questionnaire, you therefore first need to open a saved document or binder, click on the menu at the right side of the screen, and choose the *Send to Q\&A* command. The document or binder will then be transferred to a new questionnaire, and this questionnaire will be opened in the *Design Q\&A* mode. You will notice that the main menu at the top of the screen will change accordingly. ## A first look at the Design Q\&A Mode Within *Design Q\&A*, you will see the main toolbar at the top of the screen:
1. These four buttons allow you to switch between the three main contexts of the Design Q\&A Mode: the File Manager Context, the Options Context, the Editing Context and the Simulation Context. 2. Save the current questionnaire. If the questionnaire was not yet saved before, the main context will be switched to the File Manager Context. 3. Switch the language of the questionnaire. 4. Make invisible text in the underlying document visible or invisible. 5. *(only visible in the editing context)* Determine how many different panes are visible in the Editing Context, as further explained below 6. Reload the underlying document or binder. This button should only be used when some changes made by you or some other user, are not yet reflected in the preview. 7. *(only visible in the editing context)* Undo or redo ## Panes and their contents In the Editing Context, you can choose between having a single, two or three different “panes” visible on the screen. Each of these panes can show one of the following types of contents, as determined by the blue button in the upper left corner of the screen:
Cardsfor creating and editing “cards” with groups of questions
Changesfor creating and editing changes to the underlying Document or Binder, typically in reaction to the answers given by the user
Cond. & optionsedit conditions and options of a selected card, question or charge
Batch createallows you to quickly create “cards” in batch, on the basis of the datafields in the underlying document or binder
Import cards/changesallows you to copy cards and changes between different questionnaires
Edit clausesallows you to change the contents of a clause selected in the document/binder preview pane
Base document/binderpreviews the (unmodified) underlying document or binder
Test cardspreviews the cards you created through the cardspane
Test documentpreviews the changes to the underlying document or binder
Repositoryallows you to centrally define links to files used in the questionnaire, conditions used in multiple situations and custom programming functions
Notesprovides you with a notepad in which you can write internal comments about the questionnaire, for your colleages or your future self
Checksshows a panel that performs sanity checks on the structure of your questionnaire
Dependenciesshows which items depend on a selected card/questionnaire
External data inputallows you to specify how external data can be dropped onto the questionnaire (e.g., data stored in an Excel-file)
Test external data inputallows you to test the import of external data
A typical setup is to use two panes: at the left side the *document/binder* preview pane, and at the right side the *cards* or *changes* pane. This allows you to scroll through the underlying document or binder, while tweaking the cards or changes at the right side.
When a questionnaire becomes more complicated, it could become interesting to use three panes at once. Three panes will then be shown side-by-side. Of course, this can only work comfortably when your monitor is sufficiently wide — you'll not enjoy this on a 13-inch laptop screen! {% hint style="success" %} It is even possible to show the same pane twice (or even in triple). For example, in the screenshot below the *Cards* pane is shown at both the left and the right side. This can for example be useful when you are editing a card that is somewhat similar to another card in the questionnaire, and you want to be able to inspect the second card while editing the first card. {% endhint %}
# Sample clauses We offer a library of sample clauses that illustrate how the various features of Clause9 can be used. Access to this library is protected. You can access it by: * Navigating to *Assemble document*. * Clicking on the *Help* menu. * Clicking on *Clause samples*. * And finally clicking on the hyperlink that appears at the bottom of the screen.
{% hint style="info" %} All samples are located within the *Examples* library.\ \ Note that while you can experiment with these clauses, you will not be able to save your changes. {% endhint %} # Videos # Concepts and datafields ## Introduction to concepts {% embed url="" %} ## Managing concepts and datafields {% embed url="" %} ## Datafield labels {% embed url="" %} ## Using datafield predefines {% embed url="" %} ## Repeating list datafields {% embed url="" %} ## Data-expressions {% embed url="" %} # Conditions ## Writing conditional text {% embed url="" %} ## Enabling/disabling clauses {% embed url="" %} ## Conditional text tip {% embed url="" %} # Q\&As ## Creating a link to a Q\&A {% embed url="" %} ## Adding conditions to a question {% embed url="" %} ## Repeating lists in a Q\&A {% embed url="" %} ## Change placeholders {% embed url="" %} ## Change terminology {% embed url="" %} # Binders ## Binder basics {% embed url="" %} # Styling ## Basics of styling {% embed url="" %} ## Page styling {% embed url="" %} ## Locale styling {% embed url="" %} ## Reference styling {% embed url="" %} # Enumerations {% embed url="" %} # Tables ## Tables - general {% embed url="" %} ## Advanced tables {% embed url="" %} # Definitions {% embed url="" %} # Snippets ## Internal snippets {% embed url="" %} ## External snippets {% embed url="" %} # Cross-references ## Cross-references general {% embed url="" %} ## Cross-references to another document in a binder {% embed url="" %} # Special functions ## Special functions - general {% embed url="" %} ## Singular and plural special functions {% embed url="" %} # Examples of common clauses ## Party introduction clause {% embed url="" %} ## Signature blocks {% embed url="" %} # Import clauses from MS Word {% embed url="" %} # Grammatical conjugations {% embed url="" %} # Action buttons {% embed url="" %} # Alternative clauses {% embed url="" %} # Document toolbar
## Adding clauses
* if nothing is selected, the new item will be inserted at the end of the document * if a clause is selected, then: * the new item will be inserted **below** the currently selected clause * *if Shift is held* the new item will be inserted as the **last sub-clause** of the selected clause * *if Alt is held* (Option on Mac) the new item will be inserted **above** the currently selected clause You can deselect a clause by either clicking the space between two clauses, or by clicking above the first or below the last clause. | **Definition list** |

Inserts a new definition list clause into the document.

A binder can contain multiple definition lists. This allows you to, for example, create a definition list in every subdocument of the binder, whereby each definition list will only contain the terms that are unique for the subdocument it is situated in. You can even create a separate subdocument that would then aggregate all the definitions, across all of the sub-documents that themselves also contain their own definition lists.

Note that nothing will stop you from inserting multiple definition lists into a single document. Please let us know if you would be aware of a use case for such multiplicity of definition lists inside a single document.

| | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **New ad-hoc clause** | Inserts an ad-hoc clause into the document, i.e. a clause that is not intended to be reused outside the document in which it is contained. | | **New library clause** | Inserts a new library clause, i.e. a clause intended to be reused in multiple documents. | | **Existing library clause** | Allows you to select an existing library clause to insert into the document | ## Removing a clause Removes all the selected clauses from the document. Note that this action will not delete the (library) clauses themselves from the library. The only exception is when an *ad hoc* clause is removed from a document. This will effectively delete the *ad hoc* clause itself as well because it does not exist as a separate clause in the library. ## Cut / copy / paste These buttons cut, copy and paste the selected clause from Clause9's *clipboard* from/into the current document. {% hint style="info" %} The internal clipboard of Clause9 is fully independent from the clipboard of your computer. Accordingly, when pressing these buttons, the clauses will not become available towards other software on your computer. Please export the document to .DOCX if you need to get access to the text of a clause. {% endhint %} ## Increase / decrease clause level These buttons may look somewhat similar to the “increase indent” and “decrease indent” buttons in Microsoft Word , but there are quite some differences: * In Clause9, you can only *increase* the level of a clause if some other clause precedes it, which can then become an ancestor clause. In Microsoft Word, you can increase the indentation level of any paragraph. * In Microsoft Word, increasing the indent inherently causes the left margin to increase. In Clause9, it will depend on the document styling whether or not the left margin will increase. In other words, please be aware that **if styling applies that does not increase the left margin between paragraph levels, increasing or decreasing the clause level will not cause any visual differences.** * You can, however, check whether a clause is a descendant of some other clause, by selecting the presumed ancestor clause — selecting a clause in Clause9 will automatically select descendant clauses as well. ## Move clause up/down Moves the selected clauses above or below their neighbours. ## Show / hide clause numbering Shows / hides the clause’s numbering. ## Show / hide clause title Shows / hides the clause’s title. ## Export buttons Allows you to export the document to an MS Word file (DOCX), PDF file, text on the clipboard (*copy*), or email. There are many options you can configure. ## Recalculate contents This recalculates the already-available content. This may sometimes become necessary when some updates are not immediately reflected, although generally this is not needed. Please contact us when you notice that you repetitively need to press this button in order to reflect certain changes, because using this option should be fairly exceptional. The shortcut for recalculating contents is Shift-Ctrl-E. Recalculate contents does not work the same way as reload contents (available in the [Visibility settings & actions menu](#visibility-settings)). * **Reload contents** re-fetches the entire document, and all its clauses, from the server, and then recalculates the entire document. This is roughly similar to closing the document and re-opening it again. This should only be used on rare occasions, e.g. when you know that a colleague has changed a clause in his/her own browser, and you want to fetch those changes. * **Recalculate contents** does not load any contents from the server, and merely recalculates the already available content. ## Visibility settings and actions See the dedicated article on the menu with [visibility settings and actions](/assemble-document-operations-panel/visibility-settings-and-actions-menu). This menu is opened by clicking the button in the top right hand corner. # Clause hierarchies A clause hierarchy is a file type that contains a set of clauses in a fixed structure. Clause hierarchies can come in handy when you want one clause with its different levels of subclauses to be available in your clause library as one set. Users can then insert the hierarchy with one single click instead of having to find each individual clause and inserting each one separately. Except for the special locking & unlocking mechanisms [described below](#lock-unlock), a clause hierarchy acts like any regular set of clauses when it comes to numbering, cross-references, layout, and so on. Clause hierarchies can even be nested within other clause hierarchies, any level deep. They can therefore constitute an interesting alternative to using subdocuments, e.g. because subdocuments inherently start on a new page and restart their numbering by default (except if *Restart numbering* is turned off in the page styling). ## Creating a clause hierarchy A clause hierarchy can be created by selecting a clause in the Assemble Document mode that has at least one clause as its “child” – i.e. at least one subclause. Click the button in the [Document Toolbar](/assemble-document/document-toolbar) and select *Hierarchy of clauses* > *Save hierarchy as separate library clause*. Choose the location where you want to save the hierarchy and give it an appropriate file name. The end result is that you created a library clause (or, rather, a hierarchy of clauses) and that your current selection will be replaced by a reference to that library clause. Within *Browse files*, you can see that hierarchies have a special icon, to indicate that they're actually a stack of clauses bundled together. ![](/files/89XjO72JKxuGoYC7NUUt) ## How to use a clause hierarchy Clause hierarchies can be inserted in a document in the same way normal clauses are, i.e. by going to the [Search pane](/assemble-document-operations-panel/search-pane) or [Browse pane](/assemble-document-operations-panel/browse-pane) and inserting it by clicking . When selecting the hierarchy in the browse pane, a user can also choose to only add one clause that is part of the hierarchy. After inserting the hierarchy in a document, it will be easily recognisable as a clause hierarchy by the frame surrounding the hierarchy and the lock symbol.

Example of how a clause hierarchy looks when it is first inserted into a document.

### Selecting a clause hierarchy The frame around the hierarchy can be clicked to select the clause hierarchy. When selected, the clause hierarchy can be moved in its entirety using the arrow buttons in the document toolbar. Make sure you have actually selected the entire hierarchy and not just the parent clause inside the hierarchy.

This is how the hierarchy looks when it is selected.

In this case, only the parent clause inside the hierarchy has been selected and not the hierarchy itself.

### Lock / unlock Clause hierarchies – when first inserted – are locked. The fact that the hierarchy is “locked” means the **structure** of the hierarchy cannot be changed. That means the relative positions of the clauses part of the hierarchy cannot be changed. While changes can still be made to the content and other properties of any **library** clause, **ad hoc** clauses cannot be changed. This is due to the fact that the ad hoc clause is tied to the hierarchy itself, while a library clause exists independent of the hierarchy. To show that it is locked, a clause hierarchy will contain a lock symbol on the frame surrounding it. To **unlock** the clause hierarchy, click the lock symbol itself: . After unlocking, ad hoc clauses can be edited and the structure of the clauses inside the hierarchy can be freely changed. {% hint style="info" %} Similar to documents in a binder, clause hierarchies the structure of which has been edited (after unlocking) will **no longer** be ‘tied’ to the original clause hierarchy and will therefore not include any changes made to the original copy. For technical details on how the unlocking internally works, see the [discussion forum](https://discuss.clausebase.com/t/can-i-link-to-another-document-to-have-it-appear-under-the-host-document-title/338/5). {% endhint %} ## Editing clause hierarchies You can edit an existing clause hierarchy as follows: * First unlock the hierarchy by clicking on the lock-icon. * Make relevant changes to the structure (e.g., by adding/removing clauses, changing their order or indentation etc.). * Select the top-clause again. * Click on the button in the [Document Toolbar](/assemble-document/document-toolbar) and select *Hierarchy of clauses* > *Save updated clause hierarchy* * You will notice that the hierarchy gets its lock-icon again after the save. Note that Clause9 will not automatically update existing instances of the clause hierarchies in currently opened documents. You will therefore have to close & reopen documents and Q\&As that make use of the clause hierarchy that was updated. # Focus Mode Clause9 offers a special mode — called “Focus Mode” — that optimizes your workflow for dealing with a complex clause in Assemble Document. ## Activating Focus Mode Focus Mode can be activated by selecting a single clause and clicking on the button in the main toolbar. Alternatively, you can select a clause and hit the Ctrl-Shift-O shortcut. {% hint style="success" %} Tip: when you hold down Shift when clicking the button, you will immediately go to the Raw Submode instead of the Preview Submode (see below for an explanation). {% endhint %} You will notice that the the focus-button will get highlighted, and that several other tools will become unavailable on the screen.
## Submodes Focus Mode offers two different sub-modes, that have different purposes: **Preview Submode** and **Raw Submode**. You can switch between both modes by clicking on the button in the Focus Mode toolbar. Both modes are discussed in great detail below: * **Preview Submode** shows you a preview of your clause, similar to what you normally see at the left side in Assemble Document. * **Raw Submode** shows an alternative version of the “raw” content of your clause, roughly similar to what you normally see in the editor at the right side, but with a few changes optimized to deal with complex clauses. ## Datafields In both Preview Submode and Raw Submode, the bottom left side will show an overview of *all* the datafields that are somehow used in the current clause — no need to go to the Data Dashboard. You can toggle the visibility of these datafields by clicking on the button in the Focus Mode toolbar.
{% hint style="info" %} *All* datafields will be shown here, whether or not actively used in the current preview (i.e., also when a datafield happens to only be used in a part of the clause that is currently not shown because some condition is not met). This is similar to what would be shown in the Data Dashboard when you select a clause and click on the “show unused” checkbox. {% endhint %} Even better is that you can play what-if scenarios by **temporarily** **changing the datafields.** Any change you make here, will be lost when you exit focus mode. This means that you assign new values, remove values, etc. to see the impact on your clause, without “really” changing the datafields. ## Concept-labels Similar to simulating the impact of datafields, Focus Mode also allows you to simulate the impact of different concept labels, through the small pane at the right side. You can toggle the visibility of this pane by clicking on the button int he Focus Mode toolbar.
You can click on a concept-label to change its contents (using the familiar concept-label editor). If you want to experiment with the single and plural version of an existing concept-label, you can even avoid the concept-label editor by clicking on any of the buttons at the left side of a concept-label. As is the case with the datafields, any changes you make are merely temporarily. Once you leave Focus Mode, your concept-labels will return to their previous state. ## Preview Submode Preview Submode displays how your clause will look like, similar to how it is typically displayed at the left side when using Assemble Document in Normal (non-focus) Mode. Compared to Normal Mode, however, the Preview Submode will display changes to your clause a few milliseconds after you made them at the right side — no need to save your clause! This level of interactivity allows you to really “play” with complex clauses without any delays at all. ## Raw Submode In Raw Submode, the “raw” contents of your clause will be shown at the left side. At first sight, this Submode may seem to offer almost no advantages over what you see on the right side. However, read on to see why the first impression is wrong.
### Tracing your clause Raw Submode offers you the ability to “trace” parts of your raw clause, so you quickly know which parts are disabled. In the screenshot above, you will note that some parts are displayed much lighter than others — those parts are currently disabled due to certain conditions not being met. For example, in the screenshot above, you can immediately see in the third line that the word *transferable* is disabled. When you then click on any of these words, you get the following explanation:
In this case, it is obvious that the reason why this part of the clause got disabled. In other situations, however, this is much less clear. In such cases, it can help to click on the button to get a detailed explanation in a popup balloon.
### Integrated view Another reason to use the Raw Submode, is that it offers an “integrated” view of your raw clause. For example, have a look at the sample clause below: * the left side shows the “final” version, with all snippets being integrated into a coherent text * the right side shows the editor, in which the external snippet #object-of-the-license and internal snippet ALPHA are visible, but not “integrated”.
The Raw Submode offers you an integrated view of the raw text, that allows you to understand how Clause9 “sees” your text when combining everything:
You can see that both snippets (surrounded by a subtle grey border) are fully expanded, so you can check whether this was indeed the integration result you were looking for. This will be particularly interesting when dealing with placeholders, where things can quickly get so complex that you lose track of the clause:
## Isolating snippets When creating complex clauses that contain internal or external snippets, it can often help to isolate a particular snippet. You can do so by clicking on the isolation buttons that will appear automatically when you are using the preview mode, and a clause contains at least one internal or external snippet: *Full (normal view):*
*Isolated view*:
When you isolate a particular snippet, only that snippet will be shown in the preview at the left side, removing any distractions from the other parts of the clause. You can leave the isolation mode by either clicking again on the currently active (i.e., blue-colored) isolation button, or by clicking on the button at the right of the isolation bar. Besides merely removing distractions, the snippet isolation mode also allows you to understand how the software interprets a particular snippet. Have a look at the following examples, and notice how the software shows you at the left side that the result of a certain snippet is a number, date, condition, text snippet, etc.
This information can be particularly useful when you do not understand why a certain snippet does not “behave” correctly. For example, the software interprets the following snippet `ALPHA` as an “expression” of *5 augmented by 4,* i.e. the number 9. Accordingly, you could use this result for further calculations, as shown in the second screenshot:
## Assigning placeholders When placeholders are used in isolation mode, you can temporarily assign a value to those placeholders by clicking the green button:
## Spell checks Due to technical limitations in modern browsers, it's not possible to activate the spell check mode everywhere. However, we have activated the browser's spell check within the Focus mode. When you click within the clause's preview field, you will see the typical red underlining in potentially misspelled words.
{% hint style="info" %} The spell check does not work in Apple's Safari. It does work in Firefox, Chrome and Chromium-based browsers (such as Edge, Vivaldi and Opera). {% endhint %} ## Refreshing When you have saved your clause or made significant changes, it may sometimes be necessary to “refresh” your Focus Mode environment. You can do achieve this either by closing Focus Mode and re-opening it, or by clicking on the refresh button in the toolbar . {% hint style="info" %} You will lose all the changes you made to the concept-labels and datafields. But that is, of course, exactly the purpose of this refresh. {% endhint %} # Bulk generation of documents Clause9 allows you to generate a large amount of documents based on a single intelligent template created in either Assemble Document or Q\&A mode. To do so, you can request Clause9 to generate an Excel sheet containing all the questions (or, if in Assemble Documents, the datafields) present in the document template. Each row in that Excel sheet represents a separate document being generated.

Example of an Excel sheet for bulk generation

{% hint style="success" %} Be aware that, even though Excel certainly provides an easy way to quickly fill out large amounts of information, it is a fairly primitive way to complete forms — as anyone who had to fill in administrative forms in Excel would know. Generating documents in Clause9's Q\&A within a browser should be preferred whenever possible, because there are dozens of facilities offered in this browser mode that Excel simply cannot match. By way of example: it is notoriously difficult to enter multiple lines in an Excel cell. Make sure to read the guidance below to see how to effectively fill out this information so that Clause9 can interpret it. {% endhint %} {% hint style="info" %} Note that this is an advanced functionality that needs to be enabled for you to use it. Contact your administrator if you do not see the “bulk” button in the datafields menu. {% endhint %} ## Bulk creation in Assemble Document mode To download this Excel sheet directly from Clause9, open the document you want to bulk generate and navigate to the datafields menu. From there, click “bulk” on the right-hand side of the screen and then click “Excel with datafields for bulk generation”.
This will trigger the download of an Excel sheet. Once you have filled the Excel sheet out with all the necessary information, click *“Excel to generate document in bulk”* to upload it to Clause9 and receive a ZIP file containing the separate documents in the format (PDF or DOCX) of your choice. ## Bulk creation in Q\&A mode In Q\&A mode, a *Bulk export* button will be visible in the rightmost button of the export dropdown button in the toolbar.
When you choose *Bulk export*, the following dialog box will be presented:
{% hint style="success" %} In this dialog box, you can download the Excel file. Once completed, you can then re-upload it, either by clicking on or dragging over the *Choose file* button. (The *Choose file* button may look different in each browser.) Tip: you can “promote” the *Bulk export* button, so that it is shown more prominently in the Q\&A toolbar. You can do so by [setting the Global Placeholder](/admin/global-placeholders) “Promote Bulk Export” button to `true`. Example:\ ![](/files/I2rAyzOoFxcpZSyNx2Ok) {% endhint %} ## Some ground rules When you create the Excel sheet, you will see that Clause9 alphabetically orders the information that needs to be filled out based on (1) the alphabetical order of the concepts to which the individual datafields belong and (2) the order of the datafields in each concept.
You are free to play around with this structure — e.g. assign different fonts or colors —, provided you follow the ground rules below: * You can remove **row 1** containing the concept (or card) to which the questions or datafields belong. * **Row 2** (containing the question titles or datafield names) should however always be present, either as the first or as the second row. You are allowed to rephrase it — however, for currency-based datafields, the cell should somewhere mention the currency between parentheses (e.g., “(EUR)” or “(USD)”). * You will notice in the screenshot that **row 3 is hidden**. That row should not be removed or altered, as it contains the internal datafield number, that will be used by the software to match input with each datafield. * You can change the order of the columns in any way you like (the datafields of a concept should not necessarily stay together, as they are matched on the basis of the hidden datafield number in hidden row 3). * You can include a second Excel worksheet in the document explaining how the information should be filled out. However, **the first worksheet should always contain the datafields themselves**, so make sure any additional information is included in the second or subsequent worksheet. * You can remove certain columns (i.e.: datafields) if you do not want them to be filled out. This will cause that information to simply be omitted from the final documents, but does not prevent the documents from being generated. * You can add comments to a cell to assist users in filling out the Excel sheet. These will have no effect on the final output from Clause9. * You can add an optional filename in the very last column (coloured in black & white); if such filename is not included, a default one (using an incrementing number) will be added by the software . Do not add the filename extension (.PDF or .DOCX), because that extension will be automatically generated. ## Predefined values For text, number and currency fields/questions, the software will present the user the predefined values at the bottom of row 2 in the Excel file. (For example, in the screenshot above, predefined values *Belgian, Dutch* and *French* are mentioned in column A.) If no predefines are defined at the level of the question (or if the export is done from Assemble Document), the predefined values of the datafield within the concepts will be taken. ## Datafield types
Datafield typeHow to fill out cells containing this datafield
Text

A simple text value should be included here.

Note that if this text datafield is used to enable or disable conditional text, you should inform your users of the selection of values that should be filled out here. The predefined values for this datafield are a good place to start.

True/false

The word “true”/”yes” or “false”/”no” (its capitalisation does not matter) should be filled out here. Note that this is language-sensitive so that you may also fill the equivalent in your own language out. (However, English is always accepted.) For example:

French: “vrai”/”oui” or “faux”/”non”
Dutch: “juist”/”ja” or “fout”/”nee”
German: “wahr”/”ja” or “falsch”/”nein”
Lithuanian: “teisingai”/”taip” or “neteisingai”/”ne”

NumberA number should be filled here. For example: “3” (but not “three”).
DateA date can be filled out here in any (Excel-legible) format you prefer. For example: “1 October 2021” or “2021-10-01”. Excel will automatically configure the appropriate date notation format based on your input.
Duration

Here you should fill out a number along with the duration value of your choice. For example: 3 months, 5 years, etc. Note that this is language-sensitive so that you may also fill the equivalent in your own language out.

As a reminder, Clause9 uses 5 duration values to choose from: years, quarters, months, weeks, and days.

Floating point numberA number with any amount of numbers after the comma can be filled out here. Excel will automatically configure the appropriate notation format based on your input.
CurrencyA number should be filled out here. You can can configure the cell settings directly in Excel to choose the currency you would like to apply (e.g. USD, EUR, GBP, etc.)
List of textsA simple text value should be included here. Note that you can fill out multiple text values (as is the nature of the list of texts datafield) by separating each answer with a line break (using Alt + Enter (Windows) or Cmd + Enter (Mac)).
Repeating listNot supported (ignored).
# Exporting documents Clause9 provides many options when exporting documents, available from the [Document Toolbar](/assemble-document/document-toolbar):
## Type of export Clause9 currently supports the following export formats:
DOCXExports to a Microsoft Word (DOCX) file
PDFExports to Portable Document Format (PDF)
Copy to clipboardCopies the text on your computer’s clipboard, so you can paste it in other software

Depending on the browser you are using and the software you are pasting the software in, this may result in some formatting (particularly line indents) getting lost. If you require strong layout fidelity, please do not use this copy operation: instead export to MS Word and copy/paste from within MS Word.


Email attachment

Embeds the document as an attachment (either DOCX or PDF) of an email

If you are using Windows, Clause9 actually exports towards a .MSG email file intended for consumption by Microsoft Outlook (and some email programs as well). On other operating systems, Clause9 exports to a .EML file, which can be read by many different email programs.
It is possible that exporting a document as an email attachment is not possible in your orgnanisation’s network due to security settings. Please contact your administrator if you are having problems exporting a document in this manner. ## Export options When you click on the options button in the toolbar, you see a host of options that configure how your document will be exported. Note that not all options apply in all situations.
### Exporting translations ClauseBase allows you to export a multi-language document into two or more columns. The typical use case is a situation where one of the parties to a contract does not understand the main language of the contract — for example in an employment context with a foreign employee, or in situations where for regulatory reasons a contract needs to have a different language than the parties’ language.
You can export multiple languages by checking one or two additional languages besides the currently active language. Optionally, you can then also configure: * When **borders** is checked, borders will be inserted in between the columns. * When **landscape rotation** is checked, the page will always be rotated towards landscape, irrespective of the current *page style* settings. In most cases, this will be preferred for legibility reasons. In exceptional cases — typically the signature boxes — you may want to export a specific clause in a single language only, instead of being printed in two different columns.\ \ If such is desired, then select the clause in question and under *advanced* check *don’t translate in multi-language output.* (If you are the clause author and would like this single-output to be the default, then check the identically named option under the clause’s *custom styling*).\ \ In the example below, you can see that the signature table is only printed once (with the employee’s signature at the left side and the employer’s signature at the right side). After all, if this document would actually get signed, then it would make little sense to have a cramped, two-column table at the left side and an identically cramped table at the right side.
### Export comments If this option is selected, all *legal comments* will be printed in the document, through MS Word’s comments functionality.
### Export with … changes The document should be saved at least once before this option will be visible. This setting configures whether any changes vis-à-vis the original template should be shown in the output.
* **export with no changes** is the default: no changes will be visible at all * **export with changes** will export a single file, with changes visible through MS Word’s markup feature *(track changes)* * **export with changes & without changes** will export two files (combined in a ZIP file): one with no changes visible *(aka the “clean version”)*, and another with the changes visible * **export with changes in PDF & version without changes** will also export two files (combined a ZIP) file, but will force the version with changes to always be outputted as PDF. This option will be equal to the previous option when you would choose PDF as the output format, i.e. when you would press the button. ### Apply protection This setting allows you to define whether the outputted MS Word file should receive some sort of protection.
{% hint style="info" %} This setting will have no effect when outputting to a PDF file. {% endhint %} * **Do not apply protection in .docx** is the default: anyone can edit the file, without restrictions, and without any change tracking * **Do not allow changes**: will not allow any changes to be made to the MS Word file without the password * **Allow only comments:** only allows comments to be made (no other types of edits) without the password * **Only allow completing forms:** allows you to protect a document, with the exception of certain forms that can still be filled out. This functionality is enabled through the use of the [textbox special functions](/special-functions/special-items) * **Enforce tracking of changes:** allows all edit operations to be made, but will always track those changes (i.e., without the password, it will not be possible for the receiver of the file to turn off *track changes* in MS Word) # Assemble Document - FAQ
What does the lock symbol mean? The lock symbol can be seen in a document that is part of a binder. As long as the document is locked, it means (among others) that: * certain actions cannot be taken, such as changing the order of clauses, inserting new ones or removing clauses from the document; and * any updates made to the ‘original’ document (i.e. the document outside of the binder) will also be automatically made to the document in the binder, making sure any updates to the template are reflected in the binder template as well. Unlocking a document (by clicking the lock symbol) then has (among others) the following effects: * clauses can be (re)moved and inserted freely; and * importantly, the link between the original document and the document in the binder **disappears**, meaning that any changes made to the original document will **not** be reflected in the document in the binder. **In view of the fact that unlocking a document breaks this link between the document in the binder and the original document, careful consideration must be given prior to unlocking a document in a binder!** *For more information, please consult the manual article on* [*locked documents*](/binders/unlocking-documents-in-a-binder)*.* *Clause hierarchies also have a lock symbol once they are inserted in a document. Check out this* [*article on clause hierarchies*](/assemble-document/clause-hierarchies) *for more information.*
Can I make a library clause conditional without affecting other documents? Yes, you can. However, making a change to a library clause applies that change to all uses of the clause. Not only all future uses, but also all uses of the clause in existing documents as well. That is why it can be dangerous to change a library clause. There is, however, a way to work around this to make your entire clause conditional for your specific document. 1. Insert the clause into your document. 2. Select it and click the pencil icon, then click *Convert to independent ad hoc clause.* 3. Add the [condition](/clauses/writing-conditions) you want to the “[enabled?](/clauses/enabled)” property of the ad hoc clause. 4. Hit *Save*. After going through these steps, your clause should have become conditional (using the condition in the ad hoc clause). You can do this for a clause, subclause or even clauses used in an enumeration/bullet list.
What is the difference between reload contents and recalculate contents? * **Reload contents** (available in the visibility and actions menu in Assemble Document mode) re-fetches the entire document, and all its clauses, from the server, and then recalculates the entire document. This is roughly similar to closing the document and re-opening it again. This should only be used on rare occasions, e.g. when you know that a colleague has changed a clause in his/her own browser, and you want to fetch those changes. * **Recalculate contents** (Ctrl-Shift-E, available in the document toolbar in Assemble Document mode) does not load any contents from the server, and merely recalculates the already-available content. This may sometimes become necessary when some updates are not immediately reflected, although generally this is not needed. Please [contact us](mailto:support@clausebase.com) when you notice that you repeatedly need to press this button in order to reflect certain changes, because using this option should be fairly exceptional.
Is it possible to display condition explanations when exporting a document? The 'uncovered export' feature generates a Word document that displays all permutations of conditional texts in clauses. Additionally, Clause9 can generate an explanation understandable for users that are not familiar with Clause9's syntax of the conditions, clarifying when the relevant wording is displayed. This 'uncovered export' feature can be found in the 'Assemble document' menu, and by then clicking the three dots on the right side of the screen: The user has the option to choose for the Word document to have (i) the explanation above the conditional text, (ii) the explanation to the right of the conditional text, or (iii) no explanation at all, showing only all permutations. Suppose we have a condition whereby, depending on the chosen country as the answer given by the user, the appropriate court will be displayed in our document. In the clause grammar, this would look as follows: {% code overflow="wrap" %} ``` The courts at {#applic-law^jurisdiction = "Belgium": Brussels | "France": Paris | "Germany": Berlin} ... ``` {% endcode %} It would then appear as follows in the uncovered export document: As you can see, the uncovered export shows that there are three possibilities in this condition, i.e. "Brussels", "Paris" and "Berlin" and that these are tied to the choice of resp. "Belgium", "France" or "Germany" in the question (datafield) for the applicable law.
# How to: Assemble Document * [Insert images](/assemble-document/how-to-assemble-document/insert-images) # Insert images This page describes how to insert images in the body text of a document, through the special grammar of Clause9. You can upload .PNG or .JPG image files, but also .PDF files.\ The image files can be directly inserted as part of the header or footer of the [page styling](/styling/page-styling).\ \ The PDF files can be used for different purposes (including pages before/after the main content, inserting graphics-heavy headers/footers, including watermaks, etc). This is not further discussed here. ## First step: uploading the image Images are just another type of file that you can create in the file system, similar to how clauses, documents, binders and concepts are also files. * Go to *Browse files*, click on and select *Image / PDF / MS Word DOCX.* * Give the image a descriptive *File name*. * Perform the actual upload under the *Upload* tab. Both .PNG and .JPG file types are accepted.
## Second step: including an image in a clause You can insert the image in a clause by use the `@image(file)` [special function](/special-functions/introduction), optionally complemented by one or more optional additional parameters. * The file-parameter is one of the following * a hashtag and a reference to the image-file, similar to how you would refer to a #concept (i.e., the software will invite you to specify which file you are actually referring to) * a URL (enclosed in single or double quotes) * a text datafield containing a URL (e.g., #corporate-logo^url) * a text datafield containing the image data itself, uploaded through an “image” question in the Q\&A * The optional parameters can be one of the following: * maximum width/height * maximum width/height, border-width and color * width, height * width, height, border-width and color * To be used as follows: * the maximum width, width, height and border width can be expressed in centimeters (“cm”), millimeters (“mm”), inches (“i), points (“pt”) or pixels (“px”). If no unit type is specified, then pixels will be assumed * the maximum width/height refers to one measurement, which will be used to determine either the maximum width (if the image is wider than high) or the maximum height (if the image is higher than wide) * for example, a 10cm x 5cm image will be scaled down to 6cm x 3cm when using *@image(#some-file, 6cm)* * the color should be expressed in the so-called “hex” format, a set of six characters — many software programs and color pickers will show you this format when selecting a color, alternatively you can use a website such as [www.color-hex.com](https://www.color-hex.com/) or [www.w3schools.com/colors/colors\_picker.asp](https://www.w3schools.com/colors/colors_picker.asp) * alternatively, you can also use one of the following human-readable colors: *black, grey, gray, white, salmon, red, pink, orange, gold, yellow, lavender, violet, fuchsia, purple, green, olive, teal, cyan, blue, navy, brown or maroon* * don’t forget to enclose the color in quotes! ## Examples * `@image(#cb-logo)` * `@image(#cb-logo, 3cm)` * `@image(#cb-logo, 280px, 160px)`
* `@image(#cb-logo, 3cm, 4pt, "black")`
* `@image(#cb-logo, 3cm, 4pt, "#ff6666")`
# Operations panel The right part of the Assemble Document mode (next to the document preview on the left) is the operations panel. In this panel, you can edit and further customize the document. This article contains a short explanation of each of the tabs of the operations panel. {% hint style="info" %} Some tabs or buttons listed in this article may not be visible to you, e.g. because they are only visible to more advanced users or users with other types of access rights to the file you are viewing. {% endhint %} ## File
Under the file tab, you can save the document you are making in a location of your choosing, or save a copy of a document that was already saved elsewhere. ## Edit
This tab will only be visible if you are editing a clause (or e.g. a concept) inside the Assemble Document mode, for example after creating a new library or ad hoc clause or after having double clicked an existing clause in the document. In this tab, you can edit a clause or concept the same way you would in the Browse Files mode. ## Document {% hint style="warning" %} The document title will only be visible if you are editing a document and not a binder. Refer to [Binder](#binder) below for information on the binder tab. {% endhint %}
Under the document tab, you can edit various properties of the document itself. ## Binder {% hint style="warning" %} The binder tab will only be visible if you are editing a binder and not a document. Refer to [Document](#document) above for information on the document tab. {% endhint %}
Please refer to the article on the [binder pane](/binders/binders-general) for more information. ## Search
In the search tab, you can look for a clause based on its title or contents. The results can be filtered based on attributes, the location of the clause or any links the clauses contain. Adding a clause to your document can be done by one of these plus signs next to the relevant clause. ## Browse
The “browse” tab works in much the same way as the Browse Files page does. The main differences are that: * you can add a clause directly to your document * you cannot create, edit or move files when in the Assemble Document mode (you can create new folders, however) Having browsed to the clause you want to add, clicking it will show a preview of its title and body text in the bottom pane. You can then add it by clicking one of the plus signs as explained above under the [Search](#search) pane above. ## Terms
In the Terms pane, you will be shown an overview of all concepts used in the active document. You can click on each term to change the concept label tied to that concept. Additionally, you can change the definitions of each concept. ## Datafields
Under the Datafields pane (also called the *Data dashboard*), you get an overview of all [datafields](/datafields/introduction-to-datafields) used in the active document. ## Styling
In the styling pane, the custom styling of the **document** (not any selected clause) can be adapted or removed. Please refer to the [styling ](/styling/styling-overview)pane for more information. ## Advanced
The advanced pane is only visible when a clause is selected. It allows you to specify the layout of specific instances of a clause, and to configure other advanced options relating to clauses. ## Mirror
In the mirror pane, you can see another view of the active document or binder. In addition, the top slider enables you to hide certain levels of the document hierarchy. Setting it to “1” will only show the top level clauses. “2” will also show the first level of subclauses, “3” the next level, etc. This feature can provide you with a handy higher level overview of the document or binder you are editing. # File pane In the file pane of the Assemble Document operations panel, you can save the document you are making in a location of your choosing, or save a new copy of a document that was already saved elsewhere. # Edit pane This pane will only be visible if you are editing a clause (or e.g. a concept) inside the Assemble Document mode, for example after creating a new library or ad hoc clause or after having double clicked an existing clause in the document. In this tab, you can edit a clause or concept the same way you would in the Browse Files mode. # Document pane {% hint style="info" %} The document title will only be visible if you are editing a document and not a binder. Refer to [binder](/assemble-document-operations-panel/binder-pane) for information on the binder pane. {% endhint %} Under the document tab, you can edit various properties of the document itself. ## Document title The document should have a title (e.g. “share purchase agreement”). You can choose whether or not the document title should be printed, i.e. shown in the exported document. The position & formatting of the document title can be adapted in the page section of the [styling ](/styling/styling-overview)pane. ## Table of contents (TOC) Clause9 can automatically generate a table of contents in the exported document. You can choose how many levels such table of contents has…
… and also indicate where the TOC should be inserted:
{% hint style="success" %} If you desire more control over how the TOC is inserted (e.g., because you want it to be inserted at a different location — e.g., before a particular subdocument in a Binder — or you want to be able to dynamically define whether a TOC should be inserted, then you should have a look at the `@toc` [special function](/special-functions/introduction). If your users encounter problems when updating the TOC in MS Word, you consider using the `@toc-o1` [special function](/special-functions/introduction) instead, which tries to circumvent an unfortunate technical limitation of MS Word. {% endhint %} ## Document properties Clicking the Properties button
will open the document’s properties as a separate item under the edit tab. Here, you can adjust the file name, description, category, attributes, links, conditions for enabling the document (for use in binders), legal comments, custom styling (which is the same as editing the document’s styling under the styling tab) and access rights. ## Document mapping Mapping is a feature that gives you more flexibility in using clauses and makes clauses more re-usable. Specifically, document mapping is used to re-map entire concepts or specific datafields used in **an entire document** to other concepts or datafields in that document. {% hint style="info" %} Mapping of concepts or datafields can also be limited to a specific clause. This is done by selecting the relevant clause and going to the mapping subtab in the advanced pane of the operations panel. {% endhint %} For example, suppose we are making a commercial agency agreement with two parties: the principal and the agent. The document contains three concepts: principal, agent and agreement. Let’s say we need a governing law clause. This clause is already available in our library, but specifically made for a share purchase agreement. The clause makes use of the concepts “buyer” and “seller”: ``` #Buyer and #seller agree that #°agreement will be governed by Belgian law. ``` This will result in the following text: “The Buyer and the Seller agree that this Agreement will be governed by Belgian law.” Using mapping, we can ensure that **in this document only**, the concepts buyer and seller are replaced by principal and agent by mapping from buyer to principal and from seller to agent as follows: Click the *Mapping* button.
You will see this:
In the drop-down list “map from”, choose the concept you wish to **replace**, e.g. “buyer”. Then in the list “map to”, choose the concept that you want to actually be **used in the document**, e.g. “principal”. After clicking the button, all instances (including their datafields) of the “from” concept will be mapped to the “to” concept. In our example, “The Buyer” will be replace by “The Principal”. {% hint style="success" %} If a concept that is mapped to another concept contains a datafield that the other concept does not have, that datafield will remain visible under the **old concept** in the data dashboard. {% endhint %} **Mapping datafields** works in exactly the same way, but only maps a specific datafield to another. # Binder pane in the operations panel Instead of the “document” button in the operations panel, binders will replace this with a “binder” button, which looks like this when opening a new, empty binder:
In this menu, you can insert new or existing documents, rearrange their order and provide them with short titles for easy referencing (e.g.: “Annex 1” or “Pricing Schedule”). *** ## Managing documents ### Adding an existing document Uploading an existing document lets you choose a document from your library to insert into the binder. Inserting a new document occurs in exactly the same way as you would create a new document outside the context of a binder. When you insert an existing document into a binder, you are essentially creating a copy of that document that communicates with the original document but does not communicate back to it. For example: if you switch the order of a few clauses in the original document, those changes will be reflected in the binder. If you do the same in the binder, those changes will not be reflected in the original document. **For important adjustments to be made to the base document, it is therefore recommended to do this outside the context of the binder.** ### Adding a new document There is also the possibility to add a "new document". Choosing this means that you are creating a document in this binder that functions similarly to an [ad hoc clause](/clauses/how-to-clauses/create-an-ad-hoc-clause). The newly created document will only exist inside of this document and will not be accessible as a separate document in the library. It will therefore also be "[unlocked](/binders/unlocking-documents-in-a-binder)" by default. However, if you would eventually want to re-use this document either as an independent standalone document or as an existing document in another binder, you can save the document as an independent document by clicking the relevant option here:
*** ## Titles & numbers of subdocuments As usual, numbering can easily get quite complex within legal documents, due to a mix of inherent complexity and limitations in MS Word. The numbering of subdocuments is no different, but Clause9 offers multiple approaches to cope with situations. In what follows, we go deliberately quite deep into this subject, so you can completely understand what's going on, and also know how to maintain the resulting DOCX files after they have been generated by Clause9. ### Basics Essentially, when creating a cross-reference, MS Word requires you to either target an automatically numbered paragraph, or to target some bookmark. Both approaches have advantages and disadvantages * **Bookmarks** around title paragraphs have the advantage that they're more flexible. They have the disadvantage that it takes more knowledge and time to assign such bookmark to document titles once you're maintaining your MS Word file after it was generated by Clause9. Bookmarks also have the disadvantage that you have to create two separate bookmarks in MS Word (one around the number of the document title, one around its body text) when you want to sometimes refer to just the number of the document's title, and sometimes to both the number and the text of the document's title. * **Automatically numbered paragraphs** can be created using **MS Word styles** that are assigned to title paragraphs. This approach works well when the automatic numbering system is not too difficult — which may not always be the case, e.g. when Annexes & Schedules have complex or strange numbering requirements for historical reasons. They have the advantage of being easy to assign in MS Word to document title paragraphs. Clause9's approach is designed around the possibilities of MS Word for cross-references of automatically numbered titles. By default, Clause9 uses the bookmarking system. The automatic numbering system is an optional setting that can be activated, as described below. {% hint style="success" %} For a deep dive into automatic numbering in MS Word, see our [separate blogpost](https://www.clausebase.com/msword/numbering). {% endhint %} ### Practical example Let's take a simple example and use it to explain the different options that are available, as well as the rationale behind Clause9's title/numbering approach. #### Standard approach in Clause9 Suppose we have a simple binder with three subdocuments: a main body and two annexes.
The main document references the two other subdocuments through simple [cross-tags](/clauses/cross-references) assigned to those subdocuments:
Clause9 will automatically create bookmarks around each of the three subdocument titles. You can see these bookmarks when going to the *Bookmarks* option in the *Insert* tabsheet of the MS Word ribbon. (The bookmark names are deducted from the crosstags or the short/long titles assigned to a subdocument in the binder configuration, but MS Word constrains which characters can be used inside of the bookmark names.)
Inside of MS Word, you can create a cross-reference to a bookmark by going to the *Reference* tabsheet of the MS Word ribbon, clicking on *Cross-reference* and then choosing "Bookmark" in the upper-left corner of the dialog box that appears.
Inside of this dialog box, you can then choose the relevant target subdocument and hit the *Insert* button at the bottom of the dialog box. This will insert a clickable cross-reference to the target subdocument; in its default configuration, MS Word displays such cross-references in light grey on the screen.
When you would change the wording of the title of the subdocument, the cross-reference will automatically change when you update the cross-references (e.g., by printing the document, or by selecting everything and then hitting either F9 on your keyboard or right-clicking and choosing *Update Field*). #### Automatic numbering approach in Clause9 In the example above, the numbers of the subdocuments were hardcoded, i.e. the author typed in the 1 in "Annex 1 - Pricing" and the 2 in "Annex 2 - Technical configuration". This is fine when the numbering of your subdocuments is known in advance. However, Clause9 can also automatically assign numbers to subdocuments. You can do so by inserting curly braces within the Full title / Short title of subdocuments in the binder configuration. Clause9 will then automatically assign a number to each subdocument — e.g., skipping the number of a subdocument that happens to be disabled due to some condition not being met. Within the curly braces, you can insert up to two special numbers — either the number "1", or the capital roman letter "I", or the capital letter "A". In addition, you can add any other characters or symbols you would wish, e.g. a period or parenthesis. This way, you can add multiple types of subdocuments, with up to two levels of completely automatically generated numbers. For example, you could create the following configuration: * Annex {1} - Pricing in general * Annex {1.1} - Hardware pricing * Annex {1.1} - Software pricing * Schedule {A} - Technical details * Schedule {A} - Contact details * Schedule {A.1} - Emergency contacts * Annex {1} - Security This will create the following subdocument titles: * Annex 1 - Pricing in general * Annex 1.1 - Hardware pricing * Annex 1.2 - Software pricing * Schedule A - Technical details * Schedule B - Contact details * Schedule B.1 - Emergency contacts * Annex 2 - Security Another example: * Annex {(1)} - Pricing * Schedule {1°,1} - Hardware pricing * Form {#A} - Contact details * Form {#A} - Emergency contacts * Docket {"I"} - Security configuration * Docket {"I"} - Security requirements * Subdocket {I.A} - Security requirements for Windows * Subdocket {I.A} - Security requirements for Mac will result in: * Annex (1) - Pricing * Schedule 1°,1 - Hardware pricing * Form #A - Contact details * Form #B - Emergency contacts * Docket "I" - Security configuration * Docket "II" - Security requirements * Subdocket II.A - Security requirements for Windows * Subdocket II.B - Security requirements for Mac {% hint style="info" %} It is crucial to understand that you always type in *1*, *A* or *I* within the curly braces, even within subsequent documents. So don't type in *Annex {2}* or so! {% endhint %} #### Default approach in Clause9 The downside of the bookmark-based cross-referencing approach is that the entire text of the target paragraph — e.g., *Annex 1 - Pricing* — will always be inserted as such in the cross-reference. This is probably OK with short titles such as "Pricing", but may be less desirable when the subdocument's title is long — e.g., *Schedule 23 - Technical configuration of the customer's custom configuration* — because this entire title will get repeated every time you insert a cross-reference towards the subdocument. Many legal professionals will instead want to refer to subdocuments by only their number — e.g. *"Annex 1"* or *"Schedule 23"*. Unfortunately, there is no possibility in MS Word to create a cross-reference with a caption that differs from the target paragraph. This is also the reason why the sample binder we created above, will contain plain text for short cross-references:

Notice that "Annex 1" and "Annex 2" don't contain a light grey background: they consist of plain text, instead of bookmarks.

If you would instead switch to long cross-references, the DOCX file will include bookmark-based cross-references, because such is technically possible with MS Word:
**Using its default settings, Clause9 will only create bookmark-based cross-references towards subdocument titles when you are using the full-title cross-references (or when the full title happens to be identical to the short title). When, instead, the full title and short title would differ from each other and you are inserting short-title cross-references to a subdocument, plain text will be inserted in the DOCX-file.** The underlying reason is that the bookmark-based approach would simply not work in the DOCX-file for short-title cross-references, as the target paragraph (i.e., the subdocument title) would contain different text. If you don't like this setting, you should enable the automatically numbered Word-styles for subdocument titles, as explained in the next section. #### Automatically numbered Word-styles for subdocument titles Clause9 offers another solution: automatically numbered subdocument title paragraphs. You can activate this through the checkbox *Use automatically numbered Word-styles for subdocument titles,* situated below the subdocuments in the Binder:
When you activate this mode, Clause9 will use custom subdocument MS Word title styles with automatically assigned numbers (i.e. with curly braces) in the generated DOCX file. It will create such a style for each of the subdocuments for which you insert automatic numbers through curly braces {...} inside of the binder settings. Clause9 will automatically split the full title into a numbering section (everything from the start of the full title up to the closing curly brace) and into the body text (everything from the closing curly brace up to the end). For example, if you would enter *Annex {1} - Hardware pricing,* then (if the annex would be third one) the short title would for example be *Annex 3,* while the long title would be *Annex 3 - Hardware pricing*. The entire short title will then be used as the numbering configuration in the custom numbering setup in MS Word for the subdocument. Clause9's only requirement is that the "prefix" (i.e., what comes before the opening curly brace) remains the same across subdocuments with the same numbering format between the curly braces. If you don't respect this, you will get a warning, because your DOCX-file will then get strange numbering as a result, due to the limitations of MS Word:
For example, if we would use the following settings in our sample binder...
... then the resulting MS Word file would look as follows:
... with the subdocument titles having a special MS Word style called "Annex title" assigned to them, which contains an automatically generated number.
Clause9 will create custom subdocument-title-styles for each combination of subdocument with automatic numbering (i.e., with curly braces). For example, when the following full titles would be used: * Annex {(1)} - Pricing * Schedule {1°,1} - Hardware pricing * Form {#A} - Contact details * Form {#A} - Emergency contacts * Docket {"I"} - Security configuration * Docket {"I"} - Security requirements * Subdocket {I.A} - Security requirements for Windows * Subdocket {I.A} - Security requirements for Mac Then the following subdocument-title-styles are created in MS Word. They will all have the same formatting, but differ in their numbering: * A generic "**Document title**" and "**Subdocument title**" (not numbered) * **Annex Title**, with automatic numbering "Annex (1)", "Annex (2)", "Annex (3)", etc. * **Schedule Title**, with automatic numbering "Schedule 1°.A,", "Schedule 1°.B", etc. Note that its first (decimal) number is retrieved from the parent subdocument-title-style *Annex Title*. * **Docket Title**, with automatic numbering "Docket I", "Docket II", "Docket III", etc. * **Subdocket Title**, with automatic numbering "Subdocket I.A,", "Subdocket I.B", etc. Note that its first (upper Roman) number is retrieved from the parent subdocument-title-style *Docket Title*. * **Form Title**, with automatic numbering "Forma A", "Form B", "Form C", etc. #### Full title v. short title cross-references The full title of the subdocument will always be used when printing the title of the subdocument (except in the situation described below [under *Using custom subdocument titles*](#using-custom-subdocument-titles)). Conversely, when inserting cross-references, Clause9 can use either the full-title text or the short-title text. {% hint style="info" %} As explained above, short-title cross-references will be inserted as plain text when the setting *Use automatically numbered Word-styles for subdocument titles* is not enabled, except when the full title and short title would happen to be identical. {% endhint %} You can configure whether to use full-title cross references or instead short-title cross-references, by changing the setting *Referring to another document in a binder* in the *References* styling:
This setting simultaneously configures the cross-references for referring to clauses in other subdocuments, and referrenting to other subdocuments as such. As explained in the ?-popup, if you use the placeholder "SHORT-DOCTITLE", then short-title cross-references will be used by default; if instead you use the placeholder LONG-DOCTITLE, then long-title cross-references will be used. You can however manually override the default setting per cross-reference, by wrapping your cross-reference in a `@long-ref` or `@short-ref`. For example, if the cross-references styling would default to short-title cross-references, then cross-references like the following...
... will contain the short-title text in the resulting DOCX-file:
Conversely, when you would wrap the cross-references in a `@long-ref`...
... then the resulting DOCX-file will use full-title references (which usually will become true bookmarks):
#### Using custom subdocument titles Usually you want to enable the *Print title* checkbox for subdocuments, as this causes Clause9 to automatically generate a subdocument title as the first paragraph of each subdocument. However, there are situations where you do not want this behaviour, e.g. if you want to subject the entire subdocument's title to some condition, or if you want to dynamically control the text of the title. In such scenario, you must disable the *Print title* checkbox, and instead format some clause with a Custom styling for which the *Format as document title* setting is enabled.
ClauseBuddy will then render this clause with the same MS Word style as the subdocument titles for which *Print title* is enabled. As explained by the info-popup, the clause will get an automatically calculated number if all the following conditions are met: * you format the clause as a document-title * you enabled *Use automatically numbered Word-styles for subdocument titles* in the binder-settings for the subdocument in which the clause is situated * the clause happens to be the first in the subdocument Instead of hard-coding the title of the subdocument within the Title-part of the clause, you can also use the `@subdoc-title` [special function](/special-functions/references#short-ref-1). This will insert the text of the subdocument (as configured in the binder-settings) into the clause; when used within a binder for which *Use automatically numbered Word-styles for subdocument titles* is enabled, the {...} automatic numbering will also be dropped, because that numbering would otherwise get duplicated due to the MS Word that gets assigned to that clause in such situation. #### Limitations & caveats Because Clause9 is limited by what is possible in MS Word, you should be aware of a few surprises: * When you enable *Export subdocuments as separate files*, a binder will be exported as a bundle of separate DOCX/PDF files. Because it's not possible to create bookmarks towards paragraphs in other files, Clause9 will use plain text cross-references when you refer to other subdocuments. * When you are using a binder for which *Use automatically numbered Word-styles for subdocument titles* is enabled: * If you insert cross-references towards an automatically numbered subdocument , then Clause9 must insert two cross-references next to each other: one towards the number of the target subdocument title, and and one with the text of that subdocument title. You should be aware that MS Word sometimes inserts a double space, or drops a period in such situations. * If you include a cross-reference towards a subdocument for which *Print title* is not enabled, and there's no clause present (& enabled as per its conditions) in that subdocument for which *Format as document-title* is enabled, then your subdocument-numbering will become erroneous, because MS Word's numbering for the subdocuments will depend on having exactly one paragraph in each subdocument that is formatted with the special MS Word style for that subdocument title. Clause9 will however warn you for this situation in the binder-configuration. # Search pane In the search tab, you can search for files. While the interface can be used in a very straightforward manner, it actually contains quite a lot of power. ## Searching using keywords When you first arrive at the search pane, it will invite you to search using keywords:
For example, you could look for files containing the word `affiliate` by simply entering that word in the *content* box. Clause9 will then not only retrieve files that contain that exact word — in the file name, or in the clause title or clause body — but also: * Files that have **differently capitalised versions of that word** — e.g. searching for `house` will also find files that contain the word `House` or `HOUSE`. * Files that have **unaccented versions** of that word — e.g., searching for `repeter` in French will also find files that contain `répéter`, and vice versa. * Files that contain **synonyms** **of #concepts**. For example, if you have a concept `#vendor` and have assigned it the concept labels *vendor*, *supplier*, *seller* and *retailer* in English, then searching for any of these words will return clauses that contain the concept `#vendor`. * Files that contain **alternative forms of that word**, depending on the language. For example, when searching for `affiliates` in English, or `contrats` in French, the platform will also find files using the singular versions `affiliate` and `contract`, respectively. {% hint style="info" %} Do not overly rely on the alternative word forms search, as its effectiveness strongly depends on the language and the keyword considered. These word variations are generated automatically by algorithms that, despite their advanced nature, will often be incorrect. As is typically the case for these algorithms, English will work much better than other languages. {% endhint %} ### Using multiple keywords When you use a keyword that is used in many different clauses — e.g., *liability* — you may get a lot of unwanted results. Clause9 provides several tools to narrow down your search results: * Clause9 When you type **multiple words**, Clause9 will only show files that contain all of these words. For example, searching for `liability damage` will only show files that contain both the word `liability` and the word `damage`. * You can **exclude clauses that contain a certain word** by putting a hyphen in front of that word. For example, searching for `liability -damage` will only show files that contain the word `liability`, but not the word `damage`. * You can put **double quotes** around words to make sure they are found next to each other. For example, while searching for `liability damage` would also find files where the word liability and damage are twenty-five words apart from each other, searching for `"liability damage"` (with quotes) will only find files where those two words are near each other. (Note that unimportant stop words between them would be ignored — for example, a file containing the three words `liability the damage`, in that order, would also be found, because `the` will be ignored.) ### Advanced word searches As described above, Clause9 will optimise your keyword searches by searching for word variations and synonyms, replacing concepts with synonyms, dropping words that have little significance (such as articles), etc. Usually this smart behaviour is exactly what you want, but there are situations where you want to search without these optimisations. By choosing **bare search** in the dropdown box at the right (instead of a regular language such as English) Clause9 will perform an advanced search: * Your search input is **taken “as is”**, i.e. without any optimisations. Any character you type — even a quote, curly brace, angular bracket, etc. — will need to be present exactly “as is” in the clause in order to be found. * Your search is performed **across all languages** at once. * Clause9 will not only search within the filename and (for a clause) title and body, but also in the **legal comments**, **description** and **enabled condition**. * You can combine multiple queries using the operators `_AND_` / `_OR_` / `_NOT_`. * You can use the `%` operator in your input to leave out certain characters. For example, searching for `optimi%ation` would not only find files with the word `optimization` (US spelling), but also files with the word `optimisation` (UK spelling). Be aware that the number of characters that is dropped is unlimited, so this may also find files containing **`optimi`**`se the efficiency of the organis`**`ation`**. This is particularly interesting when you want to search for the special Clause9 grammar — e.g. special @functions that were used, or certain curly braces { … } or conditions. For example, if you want to search for all clauses containing `@assigned` and `#vendor` — even if only used in the enabled condition — you could do a bare search on `@assigned _AND_ #vendor` ## Searching for attributes When you click on the button, you can add one or more [attributes](/files/attributes) to search on. For example, when searching for confidentiality clauses using the generic keyword `confidentiality`, it could be useful to filter on the attribute `mutual?` to only show mutual confidentiality clauses. Note that when you add multiple attributes, they must be simultaneously met in order for a clause to show up in the results list. ## Searching in specific locations When you click on the button, you are invited to specify the folder where a certain file must be located. Only files that are found within the specified folder, or any of its subfolders, will show up in the results list. ## Searching for specific file types When you click on the button, you can filter on a file’s type — e.g., only *folders*, or only *images*, or only *binders*. {% hint style="info" %} Search for other file types is only possible outside *Assemble Document*. The *Assemble Document* search pane always searches for *clauses* to insert. {% endhint %} ## Searching for links In Clause9, a clause can establish links to other clauses, to establish that a clause in an *implementation* of a certain concept, a *definition* for a certain concept, or constitutes an alternative for another clause. By clicking on the button, you can filter the results to only show files with a certain link. Similarly, buy clicking on the button, you can enter one or more **cross-tags** that need to be implemented by the resulting clauses. ## Adding a search result to your document If you have found a relevant clause, you will obviously want to insert it into your document. Adding a clause to your document can be done by one of these plus signs next to the relevant clause. * The **purple plus** icon adds the clause to your document with the title visible. * The **green plus** icon only adds the body text without making the title visible (this can be toggled afterwards as well by clicking the button in the document toolbar). Clicking these plus signs will show a drop-down menu that lets you choose where the clause will be inserted. If you have not selected a clause, only the following choices will be visible:
However, having selected a clause in the document on the left side gives you more options:
## Versions to show Clause9 allows you to [archive old versions of a clause](/clauses/clause-versioning), e.g. when legislation changes and certain wording needs to be changed for contracts as from a certain date. By default, all versions of a clause will show up (assuming they meet the search criteria that were specified). When you only want to show the current version of a clause, uncheck the checkbox. Note that this checkbox has no effect on clauses that are not yet versioned. ## Saving searches All your search criteria can be saved together for later re-use by clicking this button next to the “search” button. {% hint style="success" %} These saved searches are also essential when using [action buttons](/clauses/action-buttons) that allow other users to re-execute a search you saved. For example, you may create a set of search criteria that search for liability clauses in French within a certain subfolder — by saving these search criteria and then offering them to other users as part of an action button, you allow those other users to re-perform the search in the future. When new clauses would get added in the meantime, they will show up in these feature searches. {% endhint %} ## Showing additional information about search results The button can be toggled to show or hide the **location** of the search results and their attributes. ## Warnings & tips * For performance reasons, Clause9 **currently limits the number of search results to 50**. Please be aware that it can be unpredictable which files get truncated from the result list. * **Sometimes keyword searches are simply not the right search tool** — particularly when you are using fairly general keywords that are used in many different clauses. Considering [browsing](/files/browse-files) for clauses instead: digging through a subject-based taxonomy is often more in line with how legal experts “think” about certain clauses. # Browse pane The “browse” pane works in much the same way as the [Browse Files page](/files/browse-files) does. The main differences are that: * you can add a clause directly to your document * you cannot create, edit or move files when in the Assemble Document mode (you can create new folders, however) Having browsed to the clause you want to add, clicking it will show a preview of its title and body text in the bottom pane. You can then add it by clicking one of the plus signs . # Terms pane
Under the terms tab, you will be shown an overview of all concepts used in the active document. Clicking the button next to a term will show you in which clauses the term is used. Clicking on any of the clauses will make the document preview on the left scroll to and highlight the place of the clause. ## Concept labels Clicking the term itself enables you to change the concept label tied to that concept. You can: {% hint style="info" %} **Why a delete button?** If you select or create a concept label, a copy of it will be stored within the Document or Binder you are currently working in. This not only allows you to deviate from the default concept label for a specific Document or Binder, but also allows you to build up a list of alternative concept labels over time — even when you do not have the right to change the Concept itself. When you click on the list of concept labels for a defined term, you will also see the concept labels you stored in other Documents or Binders. {% endhint %} ## Definitions Definitions are separate file types which can be created in the Browse Files mode and linked to concepts. These will be shown in the document if you insert a definition list. Clicking the button on the right side next to a term will show you any existing definitions linked to the concept or give you the opportunity to create a new one (which will not be saved in the library) by clicking . If no definition should be visible in the definition list, you can click . Finally, the selected definition can be removed from the list by clicking the button. # Data dashboard
Under the datafields pane (also called the *data dashboard*), you get an overview of all [datafields](/datafields/introduction-to-datafields) used in the active document, grouped by default by: * the **concepts** to which the datafields are connected; and * the **categories** to which the different concepts belong. Each datafield that does not have a value assigned yet, will have an icon showing the type of the datafield and may be assigned a color by the creator of the datafield (dark grey is the default color). {% hint style="info" %} The meaning of such colors is custom to your organisation — please refer to the responsible person within your organisation. For example, some organisations use colors to allow users to quickly identify the most important datafields in a document. Other organisations may for example use certain colors to differentiate between “legal” values and “business” values. {% endhint %} * At the left of each datafield, you will also see a magnifying glass icon . When you click on it, you will see a popup-list that provides an exhaustive list of all the clauses where the datafield is used. * When you click on a datafield that does not yet have a value, a default value will be assigned to it. You can then modify the value anyway you like. * When some value is assigned to a datafield, you can click on the label of the datafield to scroll to and highlight the first clause where this value is currently used in the document/binder. {% hint style="success" %} When you hold Shift and click on a datafield that does not yet have a value assigned, you will also be scrolled to and highlight the first clause where this value is currently used. {% endhint %} ## Options ### Popup-menu When clicking on this icon (located in the top left corner of the *Data dashboard*), you will be shown a popup-menu that enables you to toggle the following options: * toggle grouping of datafields by category * toggle showing of datafields without a value assigned * clear all datafields * save and reload the values currently assigned to the datafields as a standard set * select one of the saved sets of datafield values (cf. previous bullet) * copying and pasting datafield values {% hint style="success" %} Do not underestimate the power of saving & reloading sets of datafield values, as made possible by this popup-menu. These features enable you to quickly *simulate* how your clauses react to certain combinations of datafields. By saving sets of datafield values, you can then switch between entire contexts to see how your various clauses “react” to the values. {% endhint %} {% hint style="success" %} Tip: you can also copy/paste datafield values between different documents/binders — if the source document/binder contains certain datafields that are not present in the target document/binder, then those will simply be ignored. You can even copy/paste datafield values between a Q\&A and a document/binder, in both directions. For the Q\&A, only questions with an associated datafield will be taken into account for the matching. See [Copying & pasting answers](/qna/copying-and-pasting-answers) for more information. {% endhint %} ### Show unused When this option is enabled, Clause9 will include *all* datafields that are mentioned somewhere in a clause. When this options is disabled (the default), Clause9 will only include datafields that are *actually* currently used. {% hint style="info" %} For example, if the body of a clause contains the text `alpha {#contract^value > 5000: #contract^name} beta`, and datafield `#contract^value` is currently set to 2000, then `#contract^name` will not be visible. If no other clause would currently use datafield `#contract^name`, then this datafield will be omitted from the data dashboard — except if *show unused* is visible. Similarly, in a condition such as `#contract^value > 5000 and #applicable-law^name = "Dutch"`, datafield `#applicable-law^name` will not be “used” when the contract’s value is currently set to 2000, because Clause9 will immediately stop evaluating the condition at the moment it notices that `#contract^value` is lower than 5000, as there is no need to perform any further evaluation. {% endhint %} ### Clause enablers Toggling this option will show/hide datafields that act as *clause enablers*, i.e. datafields used in the “enabled?” condition of a clause. {% hint style="info" %} For example, in a condition such as `#contract^value > 5000 and #applicable-law^name = "Dutch"`, both `#contract^value` and `#applicable-law^name` will qualify as clause enablers. {% endhint %} ### Text enablers Toggling this option will show/hide datafields that act as *text enablers*, i.e. datafields used within conditions that are used in the title or body text of clauses to show/hide parts of a clause. {% hint style="info" %} For example, when you would write `Alpha {#contract^value > 5000: beta}`, datafield `#contract^value` will qualify as a text enabler, because it enables/disables the visibility of text part “beta”. {% endhint %} ### Others Toggling this option will show/hide datafields that do not act as clause or text enablers. For example, if the body of a clause contains the following text: `Alpha #contract^value beta`, then `#contract^value` will qualify as “other” datafield. ### Bulk This button — only visible for advanced users — brings you to a mode where you can interact with (and prepare for) the [Clause9 API](/dev/clause9-api), e.g. by inspecting the datafields present in the document. ## Saving values in the data dashboard When the document is saved, all values that have been entered in the data dashboard will be saved as well. This has three important consequences to keep in mind: * When you close and re-open the document, those values will still be there. * If the document is used in one or more binders, those values will also be used in that binder unless another value was assigned to that datafield in the binder. * Any Q\&As attached to that document will also implicitly have that value assigned for the relevant datafield. {% hint style="warning" %} Values saved in a document will therefore affect the 'starting position' of the Q\&A: until the user of the Q\&A has answered the question with the relevant datafield, that datafield will contain the value saved in the document which means the document will be affected (e.g. because a condition will be triggered or because some information has been completed on the basis of that datafield). {% endhint %} # Advanced pane
This pane is only visible when a clause is selected. As **an exception** to the other tabs of the Assemble Document mode, the actions in this tab **only apply to the selected clause**. {% hint style="info" %} At first glance, several of the options available in this pane — such as visibility, numbering, custom styling, etc. — may seem to overlap with the settings available in the [*Edit* pane](/assemble-document-operations-panel/edit-pane), so you may be wondering which one to choose. The difference between changing those settings in the *edit* pane or changing them in the *advanced* pane, is that changes made in the *advanced* pane apply only to the selected instance of the clause. Anything you change in the *advanced* pane, will not have any impact whatsoever on other instances of the same clause in your document, or other instances of the clause in other documents. Note that this difference is only relevant for library clauses. Any instance of an adhoc clause is always unique — *i.e.,* there cannot be two instances of the same adhoc clause. {% endhint %} ## Layout ### Make clause invisible The option allows you to temporily hide a clause (and its children). The effect is similar to checking the option in the *Enabled?* part of a clause. If the *invisible clauses* option is checked in the visibility options (see the popup-list accessible through the button at the right side of the screen), the clause will nevertheless be visible, but redlined. ### Show clause title? The checkbox allows you to toggle the visibility of the optional title of the selected clause’s instance. Toggling this checkbox is identical to toggling the button in the operations toolbar. This checkbox will be hidden when no title is available in the selected clause. ### Hide all numbering The checkbox allows you to hide all the numbering in the selected clause instance and its descendant clause instances. Toggling this checkbox is identical to toggling the button in the operations toolbar. When you enable this checkbox, a secondary option will become visible. If this secondary checkbox is enabled, then the numbering of the (sub)titles will remain numbered. {% hint style="info" %} The *hide numbering* settings are “inherited” by descendant clauses, and can even be changed on a descendant level. For example, if the grandparent clause hides its numbering except for the titles, then those settings will be inherited by its child clauses, grandchild clauses, and so on. However, any of those descendants can change the setting — *e.g.,* a grandchild clause can hide its own title numbering and the title numbering of its further descendants. The only limitation is that once numbering gets completely hidden (*i.e.,* including the title numbering), it is not possible to re-enable the numbering at some descendant level. The underlying reason that otherwise “gaps” in the numbering could become visible — *e.g.,* a grandparent clause 1. that is itself not numbered, would have an unnumbered child clause, and a grandchild clause 1.1.1 that *is* numbered. {% endhint %} ### Force headings (numbers) into bullets As its description implies, the checkbox converts numbered headings into bullets. For example, if the body of a clause contains:
then enabling this setting will cause this clause’s instance to appear as if the following had been written instead:
This possibility is particularly useful to foster the reusability of a clause. ### Show as left column of the next clause The checkbox is intended as a shortcut for quickly creating two columns next to each other. * In the MS Word output, you will notice that a single-row table with two 50% width cells will be created. * Within Clause9, the two clauses will be shown next to each other with a red dotted line in between. ### Start clause on a new page When enabled, the checkbox will cause its clause instance to be the first paragraph on a page. This setting is similar to what is achieved (for all clause instances) with the *“page break before”* setting in the *custom styling* > *text flow settings of each paragraph* part of the edit pane. {% hint style="info" %} In the MS Word output, this is achieved by enabling MS Word’s *“page break before”* option in the detailed paragraph settings. Enabling this setting is strongly preferred over inserting multiple Enters (which will easily cause vertical shifting once the text size is changed, or paragraphs or clauses are inserted or deleted). Enabling *“page break before”* in MS Word is often [usually preferred over inserting a manual page-break](https://www.techrepublic.com/blog/microsoft-office/force-a-page-break-before-a-specific-paragraph/) (Ctrl-Enter, or through the *Insert > Page break* toolbar button), because this setting will be associated with the paragraph in question, so will always move together with the paragraph. {% endhint %} ### Custom styling Here you can edit if and how the numbering and title of the selected clause is being shown, make sure the clause is being shown as the left column of the clause that follows, make sure a new page is started before the selected clause, add custom styling to the title and/or body parts of the selected clause etc. {% hint style="info" %} As pointed out in the note above, any changes made in the layout section only apply to **this specific instance** of a (library) clause in the active document, and are not made to the library clause itself. This means that any future use of the library clause will not include the changes you make here. Please refer to this article for more information on where custom stylings apply. If you want to change the custom styling of an *adhoc* clause, please use the *edit* pane. {% endhint %} ### Repeat clause In the layout subtab you can also make sure a clause is repeated. The drop-down list under “repeat clause” will show a list of all “list of texts”, “number” or “repeating list” types of datafields included in the document.
The clause will then be shown as many times as the number of items contained in the selected datafield. If, for example, the datafield “name” of the concept “party” is a repeating list that is selected under “repeat clause”, and three items were inserted into “name”, the clause will be shown three times. Typical use cases for this functionality are party description clauses and signature blocks which can be repeated for as many times as there are parties (i.e. items entered into a repeating list datafield under the concept of your choice). ### Don’t translate in multi-language output This checkbox is only relevant when a document is exported in multiple languages at once. It allows you to specify that a certain clause should *not* be translated in such case, and should instead span across the different columns of the page. This is typically only relevant for signature boxes in multi-language documents that actually get signed by the parties. Obviously, in such a scenario, the signature boxes should not be translated. {% hint style="info" %} Tip: you may want to use the `@in-language` and `@multi-language` [special functions](/special-functions/introduction) to insert conditions and translate certain concept-labels or datafields in such uni-language paragraph. {% endhint %} ## Mapping This works similar to the document mapping function available under the [document pane](/assemble-document-operations-panel/document-pane), except in this case the mapping is only applied to the selected clause. Two additional buttons are shown: |

show mappings that are ‘inherited’ from encompassing clauses

|

This toggles the visibility of mappings that are already applied either in the document itself or in the ‘parent’ clause of the selected clause (i.e. the clause of which the selected clause is a subclause).

| | ---------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | |

‘map from’ selection only

|

By unchecking this, the ‘map from’ section will also contain concepts used in the document which are not used in the selected clause.

| # Styling pane In the styling pane, the custom styling of the entire **document** **or binder** (i.e., not a specific clause) can be adapted or removed. Using this pane, you can quickly apply custom stylings, either on the basis of a predefined styling template, or using some completely customised settting. For example, the following document is currently shown in in its base state, without any custom styles:
If you then apply one of the style templates that were predefined by the customer’s administrator (in casu the *Colorful* template), the result will be as follows, with a single click of a button.
You can then further customise the styling by clicking on the button. Please refer to the [styling section](/styling/styling-overview) for more information about the actual contents of all those styles. {% hint style="info" %} Please note that you are applying *custom* styling to a document, which you should ideally try to minimise to ensure uniformity across your entire office. Also be aware that once you apply a style template to a document, it will not automatically update once the style template is applied. For example, assume you have a style template “MyStyle” that assigns Times New Roman/16 points/blue to headings at the first level. If you assign MyStyle to a certain document, then that document will copy the layout features of MyStyle (*in casu* Times New Roman as a font, 16 points as the size, and blue as the color). If then, later on, you happen to change MyStyle to Arial/14 points/red, then the document in question will *not* be updated, and will continue to use the old Times New Roman/16 points/blue. In other words, those style templates are merely storage places where layout features are bundled together and simultaneously applied. Once you apply a certain style template to a document, the document will merely *copy* the layout features, and completely “forget” that those features once emanated from a certain style template. {% endhint %} # Miscellaneous pane ## Mirror
In the mirror pane, you can see another view of the active document or binder. In addition, the top slider enables you to hide certain levels of the document hierarchy. Setting it to “1” will only show the top level clauses. “2” will also show the first level of subclauses, “3” the next level, etc. This feature can provide you with a handy higher level overview of the document or binder you are editing. # Visibility settings & actions menu When in Assemble Document mode, the top right corner of the document toolbar contains a symbol. Clicking this symbol triggers the “visibility settings & actions menu”. Below is a summary of what each of these settings or actions does. ## Actions ### Browse to selected clause If a clause is selected, clicking this button will bring you to the location of the relevant clause (in your clause library) in the [Browse pane](/assemble-document-operations-panel/browse-pane) of the operations panel. ### Send to Q\&A (Assuming you have the right to create Q\&As) this button will be enabled as soon as you have saved your document at least once. It sends the document (including any inputs to datafields) to the Design Q\&A mode. ### Reload contents Reload contents re-fetches the entire document, and all its clauses, from the server, and then recalculates the entire document. This is roughly similar to closing the document and re-opening it again. This should only be used on rare occasions, e.g. when you know that a colleague has changed a clause in his/her own browser, and you want to fetch those changes. The difference with **recalculate contents** (part of the [document toolbar](/assemble-document/document-toolbar)) is that recalculate contents (Ctrl-Shift-E) does not load any contents from the server, and merely recalculates the already-available content in your browser. ### Compare with previous state Clicking this button will show what changes your last action (adding/removing a clause, changing a datafield,…) has made in the document in a manner that is similar to the track changes view in Microsoft Word. This view can also be triggered by holding the Alt-key (Option-key on the Mac) and clicking inside the document. ## Visibility {% hint style="info" %} With the exception of the *Reporting mode of document* setting, none of the settings impact how your exported document will look like! {% endhint %} ### Invisible clauses Enabled by default. Toggles whether invisible clauses are shown (in red strikethrough) in your document. Invisible clauses are clauses that are included in the document but that will not be visible in any export because the conditions for their visibility (included in its [Enabled?](/clauses/enabled) property) have not been fulfilled, or because their “ancestor clauses” are not visible. ### Invisible text (due to shrinking) Disabled by default. Toggles whether any text is visible (with a dark blue background) that is not currently visible because the [shrinking](/clauses/shrinking-clauses) level is set too high. ### Reporting mode of document Disabled by default. Toggles the [reporting mode](/files/reporting) that may hide or modify the contents of certain clauses to present a different — often shorter — view of the document. ### Clause comments Enabled by default. Toggles the symbol that, if enabled, will be shown to the left of a clause that contains a [legal comment](/files/legal-comments). ### Clause datafields indicator Enabled by default. Toggles the visibility of the light blue vertical bar shown to the left of certain clauses. {% hint style="info" %} This blue vertical bar will be shown if a clause uses at least one datafield in the *content title, content body*, *reporting* or *enabled?* section — either directly or indirectly (e.g., through [data-expressions](/datafields/data-expressions) or inclusions of other clauses). {% endhint %} ### Clause shrinking opportunities Disabled by default. Toggles the symbol that will be shown to the right of a clause that contains shrinking opportunities — i.e. text that can be shown/hidden by changing the [shrinking level](/clauses/shrinking-clauses) by using the *Shrink or expand text* menu-option in the upper-right menu. ### Clause alternatives Enabled by default. Toggles the that will be shown to the right of a clause that has one or more alternatives (based on the incoming/outgoing [links](/clauses/links) that that clause has). ## Performance The performance subsection contains settings that can be disabled to improve the speed of working in Clause9 with very large documents. ### Only render visible text in large document Enabled by default, you should probably only ever change this if you are working with *very* long documents. {% hint style="info" %} For those interested in the technical details of this setting: in documents that host less than 150 clause files, Clause9 always pre-renders *all* paragraphs, even those paragraphs that currently happen to be outside your browser’s viewport (e.g., paragraphs near the end of the document, while you are currently seeing the beginning of the document). Such pre-rendering takes some time from your computer’s processor, but provides for a very smooth experience when scrolling through the document. In most situations, the time taken to pre-render is negligble (20 to 30 milliseconds). However, in *very* long documents, it can become annoying — particularly because this pre-rendering has to be done every time you change something, or switch to a different part of the software. For such very long documents, Clause9 will therefore defer the pre-rendering until a paragraph is actually visible in your browser because you scrolled towards it. Deferring the pre-rendering is much quicker, but has two downsides: scrolling through the document is less smooth, and it will not be possible to find text (through Ctrl-F / Command-F on Mac) that is currently outside your browser’s viewport. If you want to avoid these disadvantages, and always pre-render all text, then you should disable *“only render visible text in large document”*. {% endhint %} ### Calculate clause numbering Enabled by default. Toggles whether Clause9 always recalculates the numbering of clauses on-the-fly. When disabled, clause numbering will not be automatically adapted when inserting, removing, enabling or disabling clauses or when changing the position of clauses. Probably the only situation in which you want to disable this setting, is when you are in the process of bulk inserting clauses in a very long document, and the actual numbering/cross-referencing/definitions are not relevant to you at that point in time. If this setting is disabled, you can still force Clause9 to recalculate the numbering of the current document by pressing the recalculate contents button (shortcut Ctrl-Shift-E). {% hint style="info" %} Technical details: with *every* change you make, Clause9 will need to recalculate all clause numbers, all cross-references and all definitions. (E.g., if you remove some defined term from a clause near the end of the document, then this removal may cause the term to disappear from the definition list because it is no longer used anywhere in the document, and may also cause some other clauses to disappear whose condition depended on that term being used in the document, which may cause yet other clauses to disappear, as well as impact cross-references referring to those clauses, etc.) Obviously, such recalculations can take time for very long and/or complex documents. {% endhint %} ### Calculate cross-references Enabled by default. Toggles whether Clause9 (re)calculates any cross-references inside the document/binder. *See the technical details above to understand why this (re)calculation may take time, and when you may occasionally want to disable this setting.* If this setting is disabled, you can still force Clause9 to recalculate cross-references by pressing the recalculate contents button (shortcut Ctrl-Shift-E). ### Calculate definitions Enabled by default. Toggles whether Clause9 automatically recalculates the definition list. *See the technical details above to understand why this (re)calculation may take time, and when you may occasionally want to disable this setting.* If this setting is disabled, you can still force Clause9 to recalculate definitions by pressing the recalculate contents button (shortcut Ctrl-Shift-E). # Binders: general Binders are bundles of single documents that follow the same styling, terminology, definitions, etc. (binders typically take the form of a a main agreement with several annexes attached to it, like a master services agreement with a number of statements of work or a share purchase agreement with schedules attached to it). To open a binder, click on the button on the top right-hand side of the screen when in Assemble Document mode and choose *New Binder*.
You will quickly note that binders are virtually identical to documents in the way that they are presented in the document toolbar and the operations pane. For example, the “terms” and “datafield” menu of the operations panel function in the exact same way for binders as they do for documents. How to manage (existing and new) documents in a binder is [described more in detail here](/assemble-document-operations-panel/binder-pane). # Styling cross-references to subdocuments The traditional way of cross-referencing within a single document works exactly the same as it does for binders. However, you may want to fine-tune the manner in which clauses are referenced from one document to the other. To do so, go to the “styling” tab of the operations panel and then go to the “references” sub-tab. Then click and you will see the following option:
Clicking the toggle button to the left will allow you to customize this option. You can choose to write “DOCTITLE” or “SHORT-DOCTITLE” to choose whether the full title of the document is used or a short title (as you will remember: you have the option to define both these kinds of titles in the “binder” menu of the operations panel). Depending on your choice you could for example choose to refer to an article from a different document with in the same binder as: * “article 2 of Schedule 2”; or * “article 2 of Schedule 2 – Pricing details of the Services”. # Global and local definition lists In traditional documents, you can insert a definition list as a separate clause by automatically generating it using the document toolbar. However, such functionality is often not enough: * In binders, you may run into the situation of having certain defined terms in one document and other defined terms in another. * In some jurisdictions, it is customary to have “local” definition lists containing only those terms that are present in a specific clause. Clause9 allows this kind of flexibility: for each definition list, you can define the scope and interactions with any other definitions lists present in the document/binder. To tweak these options, you should simply select the definition list, and visit the Advanced menu at the right side of your screen.
These eight (!) different options should allow you sufficient flexibility to meet all your definition needs! # Document and binder properties {% hint style="info" %} This is a clause author feature. If you are not a clause author, you may feel free to ignore the following. {% endhint %} Documents and binders can have many properties similar to clauses. To do so, go to the “binder” tab of the operations panel. Scroll down to “advanced” and click , then select the document you wish to adjust the properties of. This will then prompt a menu that is virtually identical to the menu that is shown when editing clauses.
You can also adjust the properties of the entire binder by clicking and then selecting “binder”. While enabling and disabling the binder based on certain conditions may not be useful, there are plenty of other properties that may be worth adjusting for a specific binder. For example, you may want to provide a description, add certain attributes or provide certain legal comments to your users. * [**File name**](/files/file-name) **—** Allows you to set the file name of the document or binder file, optionally in multiple languages. Similar to the file names you would use on your Windows pc or Mac, file names should not be too long, to allow users to quickly glance over lists of files. * [**Description**](/files/file-description) **—** An optional pane that allows you to provide a description of a file. Users typically store either a summary of the document, and/or store practical guidelines on how to use the document — e.g. how this file is different from another file. This content can later be searched on. Unlike file names, there is no real limit to the length of the description you can provide. * [**Attributes**](/files/attributes) **—** Allows you to assign various attributes to the document, to make it easier for users to check whether the document is appropriate for their purposes. * [**Links**](/clauses/links) **—** Allows you to create relationships between files. For example, if a document is an implementation of a certain concept, that is a link you would make here. This pane can also be used to create [cross-references](/clauses/cross-references). * [**Enabled?**](/clauses/enabled) **—** Allows you to define conditions to define when the document will be visible or invisible in a binder. * [**Legal comment**](/files/legal-comments) **—** Allows you to create comments for the users of the document. * [**Custom styling**](/files/custom-styling) **—** Allows you to define custom styling for this document which will be applied each time this clause is used. This page configures the same settings as [the styling pane](/assemble-document-operations-panel/styling-pane) in the Assemble Document mode. Please use with caution: see our [tips on the use of styling](/styling/tips-and-tricks) for more information. * [**Access rights**](/files/access-rights) **—** Allows you to manually determine who the owner of a file will be (if you want to designate someone other than yourself) who will then have editing rights over this file. You can also determine access rights for everyone except the owner. * **Cross-tags —** Another way (other than using links to clauses implementing a certain concept) to create cross-references within the document/binder. For more information, see [Cross-references](/clauses/cross-references). # Styling of a Binder versus subdocuments When you create a Binder — i.e., a collection of individual subdocuments — the question arises how each subdocument should be shown when there are discrepancies between the styling settings of the Binder and the styling settings of one or more subdocuments. {% hint style="danger" %} The complexity described below is [once again](/files/custom-styling) a hint that you should try to avoid, as much as possible, to embed custom styling settings into subdocuments. Ideally, neither the Binder nor any of the subdocuments contains any styling information, so that all styling information emanates from the customer’s or user’s individual settings. {% endhint %} Clause9 assumes that the subdocuments of a Binder will generally have to look similar, and therefore takes the following approach: * **Only page-related styling settings can be different between subdocuments.** This, for example, allows you to have subdocuments that have different headers, footers or numbers of columns. * For those page-related styling settings, the settings of the Binder will serve as the starting point for each subdocument, and will be complemented by the specific page-settings of each subdocument. * Note that the document-title is not considered part of the page-related styling settings, even though its setting is listed under “page”. * **All other styling settings (including the document title) will be identical across all individual subdocuments of a Binder.**To determine which styling setting will take precedence, the following rules are used: * the Binder’s setting for a specific styling element will always take precedence * if the Binder does not contain a setting for this styling element, the main subdocument’s setting will be taken * if neither the Binder nor the main subdocument contains a setting for the styling element, the default styling for the user (perhaps determined by central customer or group styling settings) will be used. ## Example * The **Binder** contains a setting for the base left spacing (10 mm) and for the center header (“dummy center binder heading”). * The **main subdocument** contains a setting for the base left spacing (20mm), font name (Courier) and color (green), as well as a left header setting (“dummy main left heading”) and center heading (“main subdocument center heading”). * The **second subdocument** contains a setting for the base font name (Impact), as well as a left header setting (“dummy second left heading”). Its number of columns in the page-settings is set to 3, and its page orientation is landscape. * The **third subdocument** contains a setting for the base font size (12pt), as well as a left header setting (“dummy third left heading”). * No customer or group styling settings apply. This will result in the following document: * **Base left spacing**: 10mm (the Binder takes precedence over the main subdocument’s 20mm left spacing). * The **base font** used everywhere will be Courier: this is the value taken from the main subdocument (font Impact specified in the second subdocument is ignored). * The **color of the base font** will be green (taken from the main subdocument, and not overridden by any of the other subdocuments). * The **base font size** will be 10pt, i.e. the system default size, because neither the Binder nor the main subdocuments specify the font size. Note that the 12pt size of the third subdocument is ignored. * **Center heading**: “dummy center binder heading” (taken from the Binder) for the second and third subdocument, because they do not contain a center heading themselves. The center heading for the main subdocument will be “main subdocument center heading”. * The **left header setting** will be different for each subdocument, because this is a setting that can be different between subdocuments. * The **number of columns** will be one (default) for the main subdocument and third subdocument, but three for the second subdocument. * The **page orientation** will be portrait for the main subdocument and third subdocument, but landscape for the second subdocument. * All settings that are not mentioned, will be taken from a combination of the customer’s setting, group settings, user settings, etc. # (Un)locking documents in a binder {% hint style="danger" %} Please read this page carefully prior to unlocking a document in a binder as doing so may have serious consequences. {% endhint %} When working in a binder, you may notice that some (or all) of the documents making up the binder contain a lock symbol.
{% hint style="info" %} The lock symbol is also visible when inserting a clause hierarchy into a document (even outside a binder). Check out the [clause hierarchy](/assemble-document/clause-hierarchies) article for more information. {% endhint %} ## Locked documents The lock symbol means the document is currently locked, i.e. that its structure cannot be changed. While the document is locked, the following actions are disabled: * Inserting clauses in the document * Removing clauses in the document * Re-ordering clauses in the document * Increasing or decreasing clause indentation * Enabling or disabling numbering or clause title * Editing any "[Advanced](/assemble-document-operations-panel/advanced-pane)" settings of a clause in the document ## Unlocking Documents can be unlocked by clicking the lock symbol itself. **However, unlocking a document must not be done lightly!** A binder is a collection of documents. Those documents can both be existing documents and documents created specifically for the binder. Documents created specifically for the binder are (i) the default document that is included when you create a new binder or (ii) any document that is added to the binder by using the button. Think of these documents as similar to ad-hoc clauses, which are also tied to the document in which they are located. Existing documents exist separately and can be updated. An existing document that has been included in a binder (without unlocking and changing it) will follow any changes made to the ‘original’ document. This is, of course, the preferred situation as any changes to the original template are also made to any binders where this template has been included. Unlocking a document in a binder and then changing the structure (i.e. taking any of the actions listed above) **removes that link**. That means that as soon as the document included in a binder is changed, that document will no longer be linked to the original document and any changes brought to it will not be reflected in the document included in the binder. {% hint style="info" %} For technical details on how the unlocking internally works, see the [discussion forum](https://discuss.clausebase.com/t/can-i-link-to-another-document-to-have-it-appear-under-the-host-document-title/338/5). {% endhint %} ## What can still be changed in a locked document? A document being locked does not mean it becomes entirely unusable. On the contrary. All of the following (and more) is still possible: * changing datafields * changing terms & definitions * exporting to pdf/docx/e-mail * changing the document title * changing styling (on the level of the binder) * change the locked document’s properties, such as: * custom styling * enabled? conditions * links * cross-tags * editing the content & properties of library clauses used in the document * etc. {% hint style="info" %} Please note that changing a document’s properties within the binder will also change that document’s properties elsewhere, even if it was unlocked & its structure changed. {% endhint %} # Binders - FAQ
What is the difference between documents and binders? **Documents** are, much as the name suggests, individual documents which contain a set of clauses. For example: a non-disclosure agreement. **Binders** on the other hand are collections of documents which have been grouped together. For example: an outsourcing agreement with a pricing annex, technical annex, etc. Every document in Clause9 can be made part of a Binder. In fact, you are strongly advised to actively edit *documents*, and to only join them together into a Binder as the very last step.
Help! I inadvertently clicked the lock symbol As explained in another FAQ, clicking the lock symbol **allows** you to take certain actions (e.g., inserting or reordering clauses). **However, until you effectively save the Document/Binder, no changes will have been made to the Document/Binder.** The actual un-linking and de-structuring of the individual clauses will only happen at the moment that you actually save the Document/Binder; as long as you have not done so, you can always try to undo your operations and go back before the moment you clicked the lock symbol (or you can close the Document/Binder and disregard any changes). In fact, even at the moment you hit save, the link between the Binder and its Documents (or between a top-clause and its subclauses) will only be broken if you effectively made changes to the structure. At the moment you perform the save operation, the server will perform an exhaustive comparison between the old and the new version of the structure; if that structure is the same, then no “unlocking” will happen at the server level. There are two ways to check whether the link still exists, or whether it is effectively broken at the level of the server: * you can re-open the Binder and check whether the lock is (still) there * you can inspect the inner contents of the file structure by hitting the icon at the right side within Browse Files The inner contents of the Binder above will then be shown. In the screenshot below, you can see that file “new binder” has two “proxies”, i.e. pointers towards inner subdocuments saved elsewhere. If a proxy is shown in **light green**, then it concerns a “full proxy” that preserves the link between the Document and its clause structure (i.e., the link is not broken — if you would open the Binder, you will see that the lock icon will appear). ![](/files/Zp9kC7QKw4d86TehhSIZ) However, if you would unlock the first subdocument in the Binder, make certain destructive changes (such s reordering the individual clauses) and then hit save and re-inspect the contents of the Binder, you will see that the proxy towards subdocument “xx” has turned **light blue**. This means that the structure of that subdocument is effectively broken up.
# How to: binders * [Make a subdocument in a binder conditional](/binders/how-to-binders/make-a-subdocument-in-a-binder-conditional) # Make a subdocument in a binder conditional There might be circumstances where the presence of a certain subdocument should be conditional. There are two main ways to achieve this: * Via conditional logic in the enabled? field of a document itself. * Via the “Disable subdocument” change set in Q\&A mode. ### 1. Via conditional logic Inserting condition logic into a document is very similar to how you would approach this for a clause. Navigate to *binder > properties* and click on the subdocument that shall be made conditional.
A new file pops up in the Edit menu, which is where the properties of the subdocument are changed. In the *enabled?* pane, the file can be enabled or disabled based on a certain condition. You could use a general condition like `#share-transfer-agreement^consent-letter-applicable = true` to activate or deactive the Annex Form of Consent Letter (see screenshot above). Just fill it out, hit save and the datafield for this condition should be visible under the “Datafields” menu. You could also make the inclusion of a subdocument conditional on whether or not a clause is included in the binder somewhere (i.e.: whether a concept or cross-tag has been implemented). Thus, we need to use the special function `@implemented` to create this condition. For example: * To make a document conditional on the inclusion of a clause that implements the concept of #confidential-information, use @implemented(#confidential-information) * To make a document conditional on the inclusion of a clause that has a crosstag by the name of “confidential-information”, use @implemented(confidential-information) For a more detailed overview of cross-references, please consult[ this article](/clauses/cross-references) and this [How To](/clauses/how-to-clauses/creating-cross-references). ### 2. Via change set in Q\&A mode Create a *Disable subdocument* change set for your Q\&A by going to the Changes panel, clicking on and choosing *Disable subdocument.* Then, simply choose the document that needs to be disabled under a given circumstance and attach a condition to this change set to activate or deactivate the document in question. For more information on how to attach conditions to change sets, check out [this article](/qna/adding-conditions). ### 3. Comparison When choosing your preferred approach, the main thing you should be concerned with is whether you need flexibility or clarity: * **Flexibility:** choose the Q\&A approach. You will not encumber your documents with conditions that lock them into a specific legal nuance, meaning you can reuse them in different situations in Document Assembly mode later on. * **Clarity:** choose the conditional logic approach. You will disable this document to all potential inappropriate use and lock it into one specific legal nuance. # Introduction to clauses What is a clause, and which pieces of information are stored along with it? ## What are clauses? As a clause in any real life contract, a clause in Clause9 is a text fragment that can be re-used in other documents. However, a well written Clause9 clause is much more flexible and dynamic: when it is re-used in any number of different contexts, it will adapt itself to its context without having to amend the actual text. Not all Clause9 clauses contain only text. A Clause9 clause can also be made into a signature block, a table, a clause can contain images, etc. ## Breakdown of clause information
When you create a new clause, you are presented with several options to provide information about it (see the column on the right-hand side in the image above). Below, we go over each pane. * **File name —** The pane currently shown by the screenshot. It allows you to set the file name of the clause file, optionally in multiple languages. Similar to the file names you would use on your Windows pc or Mac, file names should not be too long, to allow users to quickly glance over lists of files. * **Content title —** Allows you to create a (sub)title for the clause, optionally in multiple languages. When users insert the clause into a document, they can choose whether or not to show the title. * **Content body —** Here is where the text of the clause itself should be inserted, optionally in multiple languages. * **Description —** An optional pane that allows you to provide a description of a file. Users typically store either a summary of the clause, and/or store practical guidelines on how to use the clause — e.g., in which types of documents this file should be used, or how this file is different from another file. This content can later be searched on. Unlike file names, there is no real limit to the length of the description you can provide. * **Attributes** **—** Allows you to assign various attributes to the clause, to make it easier for users to check whether the clause is appropriate for their document. * **Links —** Allows you to create relationships between files. For example, if a clause contains a definition for a certain concept, that is a link you would make here. This pane can also be used to create cross-references. * **Enabled? —** Allows you to define conditions to define when the clause will be visible or invisible in a document. * **Legal comment —** Allows you to create comments for the users of the clause. The comment will be shown in the Assemble Document mode as an information symbol next to the clause which, when the mouse pointer is hovered over the symbol, shows the content of the legal comment. * **Reporting —** Here the text which is shown in the *reporting mode* should be entered. * **Position —** Allows you to define a place where the clause should – ideally – be used in a document. When inserting the clause in the document, this location will be suggested to the user. * **Custom styling —** Allows you to define custom styling for this clause which will be applied each time this clause is used. Please use with caution: see our tips on the use of styling for more information. * **Action button —** Allows you to create a button which will be shown below the clause when using it in a document. Can be used as a shortcut to a folder, as a dropdown list of clauses or to execute a saved search. * **Access rights —** Allows you to manually determine who the owner of a file will be (if you want to designate someone other than yourself) who will then have editing rights over this file. You can also determine access rights for everyone except the owner. * **Cross-tags —** Another way (other than using links to clauses implementing a certain concept) to create cross-references within the document. For more information, see Cross-references. # Clause structure Constituent elements of a clause: numbered paragraphs, bullets and blank lines. This page explains how to structure your clause, i.e. how to use clause numbering, blank lines, bullets, etc. This page does not go into styling of headings/paragraph numbering and [bullets](#bullets), which is explained elsewhere. ## Numbering ### Paragraphs Any new clause will automatically include a default paragraph number (`1.`) in its *content body*. The number `1.` denotes the first numbered paragraph. Similarly, the next numbered paragraph would have to be numbered `2.` and so on. The period is essential, as a number alone (without a period) will not trigger a new numbered paragraph. It is best practice to always start new paragraphs with paragraph numbering. Users of your clause can still choose to disable numbering by clicking the numbering button in the [Document Toolbar](/assemble-document/document-toolbar). Conversely, if there are no numbered paragraphs numbering **cannot** be enabled by users of the clause.

Numbering button in the document toolbar

The actual number a paragraph will receive is influenced by its position inside the document. A clause with three numbered paragraphs can, for example, be numbered 2.2, 2.3 and 2.4 if it was inserted (without a title) as subclause of clause 2 that has a single paragraph. Or it could be numbered 2.1.1, 2.1.2 and 2.1.3 if it was inserted as a subclause to the first paragraph of clause 2. ### Subparagraph A clause can contain subparagraphs as well. This is done by adding an additional number to the number of the main paragraph number, i.e. the first subparagraph to the first numbered paragraph would be numbered `1.1.`, the second subparagraph would be numbered `1.2.` etc. If you want to return to the original paragraph level after your subparagraphs (i.e. without starting a new numbered paragraph), you have to re-enter the original paragraph’s numbering. An example: {% code overflow="wrap" %} ``` 1. This is the first paragraph. 1.1. This is the first subparagraph to the first paragraph. 1.2. This is the second subparagraph to the first paragraph. 1. This text will be back on the level of the first paragraph (without new numbering). 2. This is the second paragraph. ``` {% endcode %} This results in the following output — notice the second-to-last paragraph!
## Blank lines A blank line can be inserted by entering two returns (i.e. hitting the Enter-key twice). One return does not suffice: Clause9 will ignore this and show the text as if there was no return present. Conversely, more than two consecutive returns will be ignored as well. Still only one blank line will be shown in that case. Blank lines can be used to start a new subparagraph that should **never** be numbered (as absent the paragraph number, no number can ever be attributed in Clause9). ## Line breaks A line break can be inserted in Clause9 by typing `%%`. The text after `%%` will be started on a new line. A line break ut will not start a new paragraph, similar to how line breaks work (“soft returns”) work in Microsoft Word. Multiple consecutive line breaks can be inserted. ## Bullets ### Regular bullets Normal paragraph numbering can be replaced by bullets. Instead of entering a paragraph number (e.g. `1.`), start the paragraph with an asterisk `*`. Similar to subparagraphs, sub-bullets can be inserted as well by adding an additional asterisk, i.e. `**` for sub-bullets to the first level of bullets. The numbering of bullets (in accordance with the [enumeration styling](/styling/enumerations-styling) settings) will continue until a new heading or (sub)paragraph is encountered. It will therefore be the case that two clauses (on the same level) which only contain bullets will be numbered continuously, e.g. (a), (b), (c) — if that would be the styling chosen in the enumeration styling settings. ### Forcing enumeration with “and” or “or” You can force bullets (inserted by using the asterisks mentioned above) into an enumerated list using “and” or “or” before the final bullet. This is done by inserting `* AND` or `* OR` (as applicable) on a separate line **before** the first bullet. For example: {% code overflow="wrap" %} ``` 1. This list will be shown with an "and" before the final item: * AND * apple * banana * cucumber ``` {% endcode %} Results in:
This enumeration will follow [enumeration styling settings](/styling/enumerations-styling). ## Paragraphs without a number or bullet Paragraphs without a number or bullet will be inserted with the same indentation as the closest preceding numbered/bulleted paragraph. For example: {% code overflow="wrap" %} ``` 1. I like the following fruits: * apple in particular the Jonagold variety * banana * cucumber except outside of the main season ``` {% endcode %} will be printed as follows:
If in this example you want to add another line that needs to “jump back” to the indentation of the first number (“*1. I like the following fruits:”)*, instead of the indentation of the last bullet, then you need to repeat the paragraph number you want to match it to. For example: {% code overflow="wrap" %} ``` 1. I like the following fruits: * apple * banana * cucumber 1. except when I am in the mood for vegetables. ``` {% endcode %} will be printed as:
Or yet another example: {% code overflow="wrap" %} ``` 1. Alpha 1.1 Beta Gamma will be printed at the indentation level of beta 1.1.1 Delta Epsilon will be printed at the indentation level of delta 1.1 Zeta will be printed at the indentation level of beta 1. Eta will be printed at the indentation level of alpha ``` {% endcode %} will be printed as:
## Comments For truly complex clauses, it can be helpful to insert comments that describe what you are doing, or why you took a certain approach. (While things may seem very obvious at the moment you are drafting it, you would be surprised how non-obvious it may be for the person who comes after — or for yourself, 6 months in the future!) You can insert such comments by preceding a paragraph with a double forward slash:
The comment will be completely ignored by the software, so you can basically write anything you want in there. # Grammar sheet When you are drafting clauses in ClauseBase, you will occasionally want to add some intelligence to them. In order for the options not to become overwhelming, we created a handy one-pager that features all the special symbols ClauseBase uses when you want to work with concepts, conditions, mathematical equations, special functions and more. Be sure to keep this one-pager close by, as it is your (completely legitimate) cheat sheet! Click the link below to take a look: {% file src="/files/lKSOMGIUAbi3AHAIBiUz" %} # Writing conditions {% embed url="" %} ## Introduction Several special grammatical structures within Clause9 allow you to write conditions. For example, in the following conditional text, the condition `#applicable-law^name` expresses the objective that the text that follows after the colon should only be shown if the datafield name of concept `#applicable-law` is equal to the word `“belgian”`. ``` { #applicable-law^name = "belgian" : ... } ``` For a list of examples, go to *assemble document* mode and click “help”. Then navigate to “clause samples” and you will be given a link to access the samples library. This library contains a number of examples that explain how certain kinds of conditions work. ## General structure In their most basic appearance, conditions follow the structure: ***left value comparison operator right value*** ### Value types The left value and right value can be any of the following value types:
typeexplanationexamples
numberwhole number, or floating-point number (with decimal part)51234
123.5
texteither between single quotes (‘) or double quotes (“)‘Brussels’
“Paris”
dateshould be expressed as year_month_day2000_12_23 (23 Dec 2000)
2016_1_5 (5 Jan 2016)
currencya (potentially fractional) number and one of the supported currencies (EUR, USD, JPY or GBP)5 EUR
6.78 JPY
durationa number and a time unit (week, year, day, quarter, or year)5 weeks
3 months
4 years
true/falsethe truth value true or falsetrue
false
lista uniform or mixed list of elements@list(5, 6, 7)
@list(‘Brussels, ‘Amsterdam’)
@list(5, ‘Brussels’, 6 days)
Floating-point numbers and currencies are supported with up to four numbers after the decimal operator. (You can type in more decimal numbers than four, but they will be ignored. For example, when *`5.34789`* would be typed in, Clause9 will use *5.3478*.) The maximum number Clause9 can store is 99.999.999.999,9999 (99 billion etc). ### Comparison operator The **comparison operator** can be any of the following:
typedescriptionexample
=equal to#applicable-law^name = ‘belgian’
!=not equal to#parties^amount != 2
<smaller than#contract^value < 2000 EUR
>larger than#contract^value > 2000 EUR
<=smaller than, or equal to#contract^value <= 2000 EUR
>=larger than, or equal to#contract^value >= 2000 EUR
inpresent in the list (or, for texts, text is contained in other text)

#competent-court^name in @list(‘Brussels’, ‘Amsterdam’)

#department^name in "Accounts payable"

!innot present in the list (or, for texts, text is not contained in other text)

#product^type !in @list(‘typeA’, ‘typeB’, ‘typeC’)

#department^name !in "Accounts payable"

### Datafields When building conditions for clauses, you can either use **static values** (e.g., `5 weeks` or `234.5 EUR`), or use **dynamic values** by referring to datafields through the syntax `#concept^datafield` (e.g., `#applicable-law^name`). Dynamic values can also be obtained through the advanced topic of [Data-expressions](/datafields/data-expressions). Unlike a static value, the actual value of a datafield is not known by the clause author, and will instead be determined by the clause user — e.g., by submitting a value in the data dashboard, or by selecting a value in a Q\&A session. At the moment Clause9 is about to show a clause, it will look up the current value, and use it in subsequent calculations. Datafields will always take on one of the value types above (number, text, currency, duration, etc.). This value type needs to be selected upfront when constructing a Concept. When the user has not yet assigned a value to a datafield, the value of that datafield is said to be *undefined*. When drafting clauses, you should take into account the possibility of such undefined values. ### Mathematical operations Numerical values can be combined in larger structures through the basic mathematical operations (+, -, / and \*). Examples: {% code overflow="wrap" %} ``` #contract^value < 5000 EUR + 2400 EUR #contract^value < 5000 EUR - #liability^cap (#contract^value * 1.2) < 5000 EUR ``` {% endcode %} Note that parentheses can be used to clarify which parts of the formula should be taken first. If no parentheses are used, then the well-known mathematical rules of precedence are used — i.e., multiplication and division take precedence over addition and subtraction, so that `1 + 2 * 3`is equal to 7 (not 9). *** ## Details ### Shorthand comparisons If the operator and right value of a comparison are omitted, then the comparison will result in *true* if the left value: * is equal to true * is equal to a non-empty text value * is equal to a number or currency that is different from zero * is equal to a duration higher than zero * is equal to a non-empty list In other words, the comparison will be *false* if the left value: * is undefined * is equal to false * is equal to empty text (“”) * is equal to a number or currency that is equal to zero * is an empty list This allows you to for example write the following shorthand conditions: {% code overflow="wrap" %} ``` { #contract^value: ... } { #contract^duration: ... } { #employee^name: ... } ``` {% endcode %} In all of these examples, the … will only be shown if the preceding datafield is assigned a decent value. If in the first example the contract value would not have been assigned, or be equal to zero, then the … will not be shown. Similarly, if the duration would not have been assigned, or be equal to zero, or if the employee’s name would not have been assigned, or be set to an empty text, then the … will not be shown in the second and third example. ### Supported mathematical conversions To a limited extent, values of different types can be combined with each other in comparisons or mathematical operations. The following rules apply:
VALUE TYPE 1VALUE TYPE 2RESULTDESCRIPTION OR EXAMPLE
numbercurrencycurrency3000 EUR + 200 results in 3200 EUR
durationdurationduration, with the time unit converted to the most relevant one (*)

5 months + 3 months results in 8 months

1 month + 3 days results in 34 days

1 year + 1 month results in 13 months

1 year + 3 days results in 368 days

datedurationdate2018_7_1 + 1 month results in 2018_8_1, while 2018_7_1 + 2 weeks + 1 year results in 2019_7_15
Be aware that chains of mathematical operations on durations can lead to multiple conversions, which can lead to multiple rounding errors. (\*) For example, `1 year + 1 month + 1 day` will be evaluated in two steps, ultimately resulting in *396 days*. – first `1 year + 1 month` (= converted to 13 months)\ – then `13 months + 1 day` (= (13 \* average of 30.417 days) + 1 = *396 days*) ### Disallowed mathematical operations The following mathematical operations will lead to errors in Clause9. * dividing a number by zero * mixing different currencies (e.g., `300 EUR + 500 USD`) * adding or subtracting dates (e.g., `2018_7_15 + 2018_1_1`*)* * mixing a date/duration and a number (e.g., `2018_7_15 + 14`*,* or `5 weeks + 6`) * mixing texts with other types (e.g., `5 July 2018 + ‘Brussels’`, or `500 EUR + ‘2 cents’`) While it is not possible to perform mathematical operations with dates, it is possible to perform mathematical calculations between dates and durations, and compare the result. For example, if you would have two dates available and would like to check whether the duration between them is beyond a certain threshold, you could write `#concept^date1 + 3 months < #concept^date2`. ### Conversion of undefined values Clause9 will automatically convert undefined values to values that make sense in comparisons or mathematical operations:
OTHER TYPEUNDEFINED WILL BE CONVERTED INTOEXAMPLE
number05 + undefined results in 5
5 * undefined results in 0
currency0 (same valuta)5 EUR + undefined results in 5 EUR
5 EUR * undefined results in 0 EUR
durationduration with length 05 days + undefined results in 5 days
textempty text("" = undefined) evaluates to true
listempty list(@empty-list() = undefined) results in true
> It is not possible to compare a date to an undefined value. (After all, a “zero date” makes little sense…) ### Combining sub-conditions: AND/OR/NOT Different sub-conditions can be combined through AND, OR and NOT. For example, the following combination of sub-conditions will only apply if Dutch law applies, and the competent court is simultaneously set to Amsterdam: ``` #applicable-law^name = 'dutch' AND #competent-court^location = 'Amsterdam' ``` Computer users who first encounter AND/OR conditions, are often confused by them, because they seem to express the opposite of common language. For example, the sentence *“Marie will go to the city when it is Tuesday and when John calls”* will usually be understood as *“Marie will go on Tuesday, but will also go on other days when John calls”*. Hence, in everyday language, the word “and” can sometimes express that something applies when any of the sub-parts apply. Whether this is indeed the case — or whether “and” should instead be interpreted as *“only apply when both sub-parts apply at the same time”* — can usually be inferred from the context. In most situations, this linguistical ambiguity is not a problem, because the context will be clear or because the consequences of the wrong interpretation are negligible. However, such ambiguities are sometimes also found in contracts and laws, and then the context may not always be clear, and/or the consequences may be significant When building conditions in Clause9, such ambiguities will not arise, because the word “AND” means *“both sub-conditions must apply”*, and is thereby clearly opposed to the word “OR”, which means *“it is sufficient if any of the sub-conditions applies”*. Much more complex combinations of sub-conditions are possible. The following combination will only apply if **either** of the following two bullets applies: * Dutch law applies and the competent court is simultaneously set to Amsterdam; or * the contract value is higher than 5.000 EUR {% code overflow="wrap" %} ``` (#applicable-law^name = 'dutch' AND #competent-court^location = 'Amsterdam') OR (#contract^value > 5000 EUR) ``` {% endcode %} Please note that the way parentheses are used, is very important. The following example is identical to the previous one, with the exception of the parentheses: {% code overflow="wrap" %} ``` #applicable-law^name = 'dutch' AND (#competent-court^location = 'Amsterdam' OR #contract^value > 5000 EUR) ``` {% endcode %} The change in parentheses causes a significant change in meaning, because the sub-conditions between parentheses will be evaluated first, before evaluating the other sub-conditions. The combination of sub-conditions will now only apply if **both** of the following sub-conditions simultaneously apply: * the applicable law is Dutch * the competent court is Amsterdam AND, in addition, the contract value is higher than 5000 EUR There is no need to put parentheses within a “chain” of AND sub-conditions. For example: `#applicable-law^name = ‘belgian’ AND #competent-court^location = ‘Brussels’ AND #contract^value > 5000 EUR` Similarly, it is also fine to create a chain of OR conditions without any parentheses. What is problematic, however, is to chain AND and OR conditions without parentheses. For example: `#applicable-law^name = ‘belgian’ AND #competent-court^location = ‘Brussels’ OR #contract^value > 5000 EUR` should this be understood as: “apply in **any** of the following situations: (1) Belgian law applies and simultaneously the competent court is Brussels; (2) the contract value is higher than 5000 EUR”, or should it instead be understood as “only apply when **both** of the following situations apply: (1) Belgian law applies; (2) either the court of Brussels is competent, or the contract value is 5000 EUR”? There are rules of precedence that dictate how the software will evaluate this combination of sub-conditions. However, these rules are rather counter-intuitive, so that it is always better to uses parentheses with any mix of AND and OR. NOT sub-conditions should always be surrounded by parentheses. Example: ``` NOT (#applicable-law^name = 'belgian' AND #competent-court^location = 'Brussels' AND #contract^value > 5000 EUR) ``` This combination of sub-conditions will apply when the following combination of situations does ***not*** simultaneously apply: * Belgian law applies * the competent court is Brussels * the contract value is higher than 5000 EUR In other words, this combination of sub-conditions will apply when Belgian law would not apply, or when the competent could would not be Brussels, or when the contract value would be lower than (or equal to) 5000 EUR. Note that AND / OR can always be converted to each other with the help of NOT: `NOT(A OR B)` is equal to `((NOT A) AND (NOT B))` `NOT(A AND B)` is equal to `((NOT A) OR (NOT B))` The previous example with a chain of ANDs can therefore also be converted to a chain of OR, with the operators (= and >) reversed: `#applicable-law^name != ‘belgian’ OR #competent-court^location != ‘Brussels’ OR #contract^value <= 5000 EUR` ### “Short-circuiting” of conditions Please note that Clause9 will stop evaluating a condition as soon as it can. In the example below, the second part (“beta”) will never be used, because: * either the contract value is higher than 5000, in which case the first part (“alpha”) will be used and the second part subsequently gets ignored * or the contract value is lower than 5000, in which case both the first and second part will be skipped {% code overflow="wrap" %} ``` {#contract^value > 5000: alpha | #contract^value > 5000 and #applicable-law^name = 'belgian': beta} ``` {% endcode %} New users of Clause9 are sometimes confused by this behaviour, but this so-called “short-circuiting” is actually a handy feature you can make use of. For instance, when testing with certain clauses or conditions, you can quickly prepend a `true: ...` condition to temporarily avoid that any of the other conditions would get evaluated. In the example below, the second and third part will be completely ignored by the software, because the first part (the short-hand condition `true`) will always be true, so the software can immediately stop its evaluation of the condition. {% code overflow="wrap" %} ``` {true: xxxx | #contract^value > 5000: alpha | #applicable-law^name = 'belgian': beta} ``` {% endcode %} Similarly, you can for safely write {% code overflow="wrap" %} ``` {#contract^interest != 0 AND (#contract^value / #contract^units > 5000): ... } ``` {% endcode %} Without the short-circuiting functionality, the software would throw a “divide by zero” error when the interest would happen to be equal to zero. With the short-circuiting functionality, however, you can rest assured that the second limb of the AND will be completely skipped when the interest would happen to be zero, because in such case the software knows that an AND-condition will result in `false` as soon as one of its limbs is false. Of course, the same is not true for an OR-condition: the software needs to evaluate each of the limbs of an OR-expression to search for any limb that happens to be `true`. # Examples of conditions ## The value must be equal to any of a set of predefined values Example: assume you only want to show some text when a property is located in any of the following cities: Antwerp, Amsterdam, Paris or Barcelona. The long way to write this is: {% code overflow="wrap" %} ``` {#property^location = "Antwerp" OR #property^location = "Amsterdam" OR #property^location = "Paris" OR #property^location = "Barcelona"} ``` {% endcode %} The shorter and more readable way to write this: {% code overflow="wrap" %} ``` {#property^location in @list("Antwerp", "Amsterdam", "Paris", "Barcelona")} ``` {% endcode %} The **wrong** **way** to write this: {% code overflow="wrap" %} ``` {#property^location = "Antwerp" OR "Amsterdam" OR "Paris" OR "Barcelona"} ``` {% endcode %} The reason the above condition does not work, is that — due to the [short-hand comparisons](/clauses/writing-conditions#short-circuiting) feature — the software will actually interpret this as `#property^location = "Antwerp" OR "Amsterdam"`` `**`= true`**` ``OR "Paris"`` `**`= true`**` ``OR "Barcelona"`` `**`= true`**, similar to how the software would interpret a condition such as `{#property^location: ...}` as meaning “if some value is assigned to this datafield, then show the following text: …. In other words, because in the wrong example above, for Amsterdam/Paris/Barcelona the comparison misses a second part, the software will implicitly “fill up” this second party with “= true”. Because the words “Amsterdam”, “Paris” and “Barcelona” obviously contain at least one character, these parts will always be true. The end result is that this condition will always be considered true, even when the property’s location is not filled in, and even when the property’s location would for example by “New York”. ## The value must not be equal to certain values Example: assume you do **not** want to show a certain piece of text for a property located in Moscow or Milan. The long and probably incorrect way to write this: {% code overflow="wrap" %} ``` {not(#property^location = "Moscow") and not (#property^location = "Milan")} ``` {% endcode %} The above example is probably wrong, because it will also show the piece of text when no value has been assigned to the property’s location, or when the property’s location has been assigned an empty text value. This is probably not what you want. To take this situation into account, you would have to write an even longer version: {% code overflow="wrap" %} ``` {#property^location and (not(#property^location = "Moscow") and not (#property^location = "Milan"))} ``` {% endcode %} This new condition first checks whether some non-empty value is assigned. If so, then it will check whether that value is not equal to either “Moscow” or “Milan”. This works, but is a bit long. This can be shortened to: {% code overflow="wrap" %} ``` {#property^location and #property^location !in @list("", "Moscow", "Milan")} ``` {% endcode %} or even shorter: {% code overflow="wrap" %} ``` {#property^location !in @list("", "Moscow", "Milan")} ``` {% endcode %} ## Two datafields must have a value equal to some predefined value Example: a certain bonus is awarded when an employee’s collective labour agreement (CLA) is either nr. 123 or 456, while at the same time the employee’s status must be *active* or *on parental leave*. The **double wrong** **way** to write this: {% code overflow="wrap" %} ``` {#employee^cla = 123 or 456 and #employee^status = "active" or "parental-leave"} ``` {% endcode %} The first error is that, due to the short-hand comparison described earlier on this page, the software will actually interpret this as `(#employee^cla = 123) or (456 = true) and (#employee^status = "active") or ("parental-leave" = true)`. This expression will always be true, because any number other than zero (such as 456) and any piece of non-empty text (such as “parental-leave”) will be considered “true” by the software. The **less wrong (but still wrong) way** to write this: {% code overflow="wrap" %} ``` {#employee^cla = 123 or #employee^cla = 456 and #employee^status = "active" or #employee^status = "parental-leave"} ``` {% endcode %} This is still wrong, because it is very unpredictable for human beings to remember how this will be interpreted by the software, due to the concatenation of AND and OR. Will the software interpret this as `(CLA = 123 OR CLA = 456) AND (status = "active" OR status = "parental-leave)`? Or instead as `(CLA = 123) OR (CLA = 456 AND status = "active") OR (status = "parental-leave)`? Or even in some other way? There exist “precedence” rules for this, but many people have problem remembering the precedence rules for addition and multiplication of numbers, so even if you remember correctly what the precedence rules are for AND/OR/NOT, the person who comes after you to update your texts will probably make a mistake in the interpretation. In any case, the above condition is hard to read. A correct solution using parentheses is for example: {% code overflow="wrap" %} ``` {(#employee^cla = 123 or #employee^cla = 456) and (#employee^status = "active" or #employee^status = "parental-leave")} ``` {% endcode %} A shorter version, which drops the concatenation of AND/OR: {% code overflow="wrap" %} ``` {#employee^cla in @list(123, 456) AND #employee^status in @list("active", "parental-leave")} ``` {% endcode %} ## A “list of texts” datafield must contain a value Example: a piece of text must be shown when an employee’s fringe benefits (a “list of text” datafield) includes both *meals* and *tuition*: The **very wrong way** to write this condition: {% code overflow="wrap" %} ``` {#employee^benefits = "meals" or "tuition"} ``` {% endcode %} This not only suffers from the short-circuiting issue described above, but will also result in an error because you are comparing a list of items (i.e., the “list of texts” datafield `#employee^benefits`) to a single text item (“meals”). For the software, this boils down to comparing apples to oranges, hence the error. A **less wrong (but still wrong) way**: {% code overflow="wrap" %} ``` {#employee^benefits = @list("meals", "tuition")} ``` {% endcode %} This will in many cases be wrong, because it will only be true if the benefits include *only* meals and tuition — i.e. if the list on the left side and the list on the right side are exactly equal and include exactly the same elements. If any other benefit would have been assigned to the employees, then this condition will erroneously become false. Even when the employee’s benefits consist of only meals and tuition, the above condition may erroneously result in false, when the *tuition* happened to come before the *meals* in the datafield, i.e. if the ordering is different. The reason is that list-of-text datafields take ordering into account — after all, in certain contracts, the order of appearance of the elements may be very important. A **correct** way to write this condition: {% code overflow="wrap" %} ``` {("meals" in #employee^benefits) AND ("tuition" in #employee^benefits)} ``` {% endcode %} or, somewhat shorter (but also more fancy and probably less readable): {% code overflow="wrap" %} ``` {@is_subset(#employee^benefits, @list("meals", "benefits"))} ``` {% endcode %} # Using codes instead of text fragments ## Issue at stake When inserting predefined values in a datafield or predefined answers in a Q\&A question, it can be very tempting to use wording that can be inserted *as such* in the text of a document. For example, when a transport contract allows a delivery to be made in three different countries, you would be tempted to use the name of those three countries as the predefined value/answer. This is not problematic when drafting a short, single-language document where the names of those three countries are only inserted into one specific clause. However, this approach has several drawbacks: * In a multi-lingual document, you would have to use predefined values/answers per language, because the names of the countries differ per language. * Writing condition statements in the body text of a clause becomes much more complex, because the conditions would change per language. For example, `{#country^name = "United Kingdom": ... | "Germany": ... }` becomes `{#country^name = "Royaume-Uni": ... | "Allemagne": ... }` in French. * Writing enabled-conditions for a clause becomes almost impossible in a multi-lingual context, because enabled-conditions can only be drafted for a single language. * Even in a single-language context, writing conditions becomes much more error-prone, because of the length and complexity of the names. For example, the likelihood of misspelling *Czechoslovakia* (French: *Tchécoslovaquie*) is quite high. Also, different variations of country names are used — for example, should you use “*the Netherlands”* or instead *“Netherlands”* ? * With long values, reading condition statements becomes much harder because the condition part can get quite long. * Managing small changes becomes much harder and error-prone. For example, assume that a transport contract allows the user to choose between normal delivery and premium delivery. The text that needs to be inserted into the document would then be either “*delivery in accordance with the national carrier*s’ *service levels”* and *“two-day guaranteed delivery at a premium rate”*. Now assume that the delivery term is lowered to one-day delivery. Suddenly you will have to manually search for every occurrence of the text parts above, and manually change them — not only in the clauses, but potentially also in (conditions within the) Q\&A. * Text fragments cannot contain any conditions, concept-labels or datafields. Accordingly, those text fragments will not reflect changes in styling, concepts, datafields contents, etc. ## Solution The solution is to use codes instead of text fragments, optionally paired with labels and text snippets. For example, in the transport contract referred to above, the normal delivery option could be referred to with code `normal-delivery`, and the premium delivery option with `premium-delivery`. Inside a clause, you would then write: {% code overflow="wrap" %} ``` {#contract^delivery = "normal-delivery": .... whatever text needs to be inserted here for the normal delivery ... | "premium-delivery": ... text for the premium delivery stuff ... } ``` {% endcode %} This indirection through a special code may seem like more work, but will not suffer from the scalability and management disadvantages outlined above: * a code is much shorter, and therefore takes less time to type, and are less error-prone * the document text associated with a code can be independently and centrally modified * codes are language-independent, and can therefore also be used in enabled-conditions ## Tips When you frequently have to insert the same text fragment in conjunction with a certain code, it is beneficial from a management point of view to turn the text fragment into an [**external snippet**](/clauses/snippets), because such snippets allow for central updating. (If the entire conditional statement is frequently repeated, it is probably also a good idea to turn that entire statement in its entirety into an external snippet.) Another tip is to associate (possibly translated) **labels** with the predefined value or answer. This avoids that the code itself would be presented to the end-user. Please also consult the other [Grammar style guide](/misc/grammar-style-guide), for various best practices related to choosing the right code. # Bold, italic and underline ## Do you actually want to force styling? Clause9 encourages you to minimise the amount of styling you *embed* in a clause. Ideally, clauses do not contain any styling — such as bold, italic and underline — because all styling will then be completely determined by the user of the clause. This encourages *reusability* of clauses, since different departments (or even different clients of a law firm) can all use the same clause, but with widely different styling. Even so, there are situations where you can be really sure that some styling must be applied. In such situations, it can come in handy to force certain parts of the text to be bold, italic or underline. [Other styling deviations (e.g., coloring, borders, line spacing) are also possible.](/clauses/special-codes) ## Bold You can force text parts to become bold by enclosing them in `~ tildes ~`: 
Some ~bold~ word.
## Italic You can force text parts to become italic by enclosing them in \``` `backticks` `` ``` Some `italic` word. ``` ## Underline You can force text parts to become bold by enclosing them in \ backslashes \\: ``` Some \underlined\ word. ``` ## Combinations You can combine bold, italic and underline any way you like. For example: 
Some \~bold and underlined~\ words.

Some `~italic and bold~`  words.
# Special codes ## Line break If you want to start a certain word on the next line, it is not sufficient in Clause9 to simple hit Return/Enter, because Clause9 ignores a single Return/Enter characters, and starts a new paragraph when you insert two or more Return/Enter characters. You can however insert a forced line-break by inserting two percentage-signs (%%). For example: `The following items will be purchased: %% alpha %% beta %% gamma.` Will be printed as follows:
There is a huge difference between inserting a line break and starting a new paragraph. A new paragraph will insert another paragraph number, and may also receive extra spacing due to the [space above / below styling settings](/assemble-document-operations-panel/styling-pane). Conversely, a line break simply moves new text back to the left side of the paragraph, while technically remaining within the same paragraph. In Microsoft Word, you can insert a line break by pressing Shift-Enter/Return (as opposed to simply pressing Enter/Return, which will create a new paragraph). ## Deviating styling In principle, all paragraphs within the same clause (file) will be styled in the same manner. While you can apply different styling through the *“custom styling”* settings of a file, all of this custom styling will be applied to *all* paragraphs. In most cases, this is exactly what you want. However, there are situations when you want one of the paragraphs to receive a special styling that deviates from the other paragraphs of the same file. For such special situations, you can insert formatting codes between `% ... %` , right after the bullet (\*) or numbering (1., 2.1., …) of the paragraph. If you want to apply multiple exceptions at once, separate them by comma’s. For example: {% code overflow="wrap" %} ``` 1. This paragraph will be printed with the regular styling that happens to apply to this clause. 2. % align center, font color #aaa, font name Courier % This paragraph will be centered, shown in light grey, in font Courier. 3. This paragraph will be printed in the same (regular) styling as the first one. ``` {% endcode %} The following formatting codes are available — note that they all correspond to the [base styling settings](/styling/base-styling): | Code | explanation | | ------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `align left` | left-align the paragraph | | `align left first line` | left-align the paragraph, with the first line indented | | `align left hanging` | left-align the paragraph, with the bullet or number “hanging” at the left | | `align right` | right-align the paragraph | | `align center` | center the paragraph | | `align justified` | justify the paragraph | | `align justified first line` | justify the paragraph, with the first line indented | | `align justified hanging` | justify the paragraph, with the bullet or number “hanging” at the left | | `indent left xxx cm/mm/pt/i` | set the left indentation (or the first line indentation) of the paragraph | | `bold true` (or simply `bold`) | make the text bold | | `bold false` | make the text non-bold | | `italic true` (or simply `italic`) | make the text italic | | `italic false` | make the text non-italic | | `underline true` (or simply `underline`) | underline the text | | `underline false` | remove any underlining from the text | | `regular caps` | print the text with regular caps | | `small caps` | print the text in small-capitals | | `all caps` | print the text in all-capitals | | `keep with next true` (or simply `keep with next`) | keep the paragraph together with the next paragraph, on the same page | | `keep with next false` | don’t force the paragraph to be printed on the same page as the next one | | `keep lines together true` (or simply `keep lines together`) | ensure that all lines of the paragraph are printed together on the same page | | `keep lines together false` | don’t force the lines of the paragraph to be printed together on the same page | | `line spacing xxx` | set the line spacing to the specified amount *(as a percentage*, e.g. 100, 150 or 200*)* | | `page break before true`(or simply `page break before`) | ensure that this paragraph is started on a new page | | `page break false` | don’t force this paragraph to be started on a new page | | `space above xxx cm/mm/pt/i` | insert the specified amount of spacing *above* the paragraph | | `space below xxx cm/mm/pt/i` | insert the specified amount of spacing *below* the paragraph | | `space left xxx cm/mm/pt/i` |

insert the specified amount of spacing at the left of the paragraph

note that any such space will be additional space, added on top of the left-indentation that already happens to apply to the paragraph

| | `space right xxx cm/mm/pt/i` | set the right-indentation of the paragraph to the specified amount | | `font size xxx cm/mm/pt/i` | set the font-size to the specified amount (typically in points — *pt*) | | `font xxx` (or simply `font`) | set the font *(*`xxx` can be *Arial, Arial Black, Calibri, Cambria, Courier, Georgia, Gill Sans, Impact, Lato, Lora, Montserrat, Noto Sans, Noto Serif, Palatino, Roboto, Source Sans Pro, Times, Tahoma or Verdana)* | | `font color #xxx` (or simply font `#xxx`) |

set the font color to the specified colorThe font color is specified in so-called CSS hex format, which is a combination of either 3 or 6 hex characters (a number or a / b / c / d / e). For example, #FF0000 is pure red, while #22B61E is a green variant.

There are numerous websites and software programs that can help you find the right color — see for example or

| | `marginal` |

Inserts a marginal number at the left side of the paragraph (as if @marginal would have been invoked)

Note that the number will only be shown in body paragraphs or headings for which the numbering is hidden.

| | `seq "xxx"` |

inserts a sequential number of the specified list-name at the left side of the paragraph (as if @seq(xxx) would have been invoked)

For example, % seq "figures" % would insert a sequential number for the increasing list figures.

Note that the number will only be shown in body paragraphs or headings for which the numbering is hidden.

| ## Adding deviating styling to paragraphs in snippets It is possible to add deviating styles to paragraphs that are included as internal snippets. However, you then have to make sure that the snippet is treated as an entire paragraph (instead of a mere *part of* a paragraph) by starting the content with a number. For example, in the code below, paragraph number `1.` must be added to ensure that the `% page break before %` is recognised. {% code overflow="wrap" %} ``` {#contract^value > 5: @WITH | else: @WITHOUT} WITH = 1. % page break before % title with break WITHOUT = 2. title without break ``` {% endcode %} ## Signature & dotted tab Most contracts will contain a signature section, which will typically involve printing a dotted line. Inserting such dotted line is actually not so easy to do correctly in Microsoft Word. Clause9 allows you to easily insert such a dotted line, by inserting `% signature %` at the start of the paragraph, right after the number or asterisk. This will not only ensure that the dotted line is inserted, but also that sufficient space above & below the paragraph is available to make room for large signatures. For example, {% code overflow="wrap" %} ``` Executed in Brussels, on #contract^date. || ~Employer~ || ~Employee~ || || %signature% Name: || %signature% Name: || ``` {% endcode %} Will be printed as follows:
Instead of using `% signature %` you can also use `% dotted %` . This will also insert the dotted line, but does not automatically create space above & below the paragraph. #### Exclamation marks before datafields When you insert a datafield — e.g. `#employee^name` — it will be replaced by its value. However, when no value has been assigned yet, the result will be that: * a yellow placeholder box will be inserted when the datafield was used **within body text**, to invite the end-user to provide a value * the datafield will be replaced by the value `undefined`, when used **inside conditions and calculations** (depending on the condition or calculation, this may or may not lead to an error) You can reverse this behaviour by adding an exclamation mark just before the datafield-name, e.g. `#employee^!name`. Accordingly, the following will happen: * **inside body text**, in most cases\* no more yellow placeholder box will be shown when no value has yet been assigned to the datafield — in other words, the datafield is simply skipped in the resulting text * **inside a condition or calculation**, a yellow box will be shown, to invite the end-user to provide a value This exclamation mark helps to resolve the following situations: * **in body text**, it is not always necessary that a datafield has a value assigned to it, so you may not always want to force the end-user to submit a value * Example: in some countries, only some citizens will have a middle name. When you include something like `#employee^first-name #employee^middle-name #employee^last-name` in the body text, you may want to force the end-user to fill in a first name and last name (because those must always be submitted in order for a contract to make sense), but you may not want to show a yellow box for the middle name, because employees with a middle name are an exception in your country. In such situation, the missing middle name will not trigger a yellow box, but it can still be submitted in other ways (e.g., in the data dashboard, or through a question in the questionnaire) * **Some conditions and calculations** only make sense when a certain value is available. If that value is not available, the calculation should immediately stop, and the user should be invited to submit the missing value. * Suppose, for example, that in a contract with a defined duration, you would like to calculate the termination date through `{#contract^start-date + #contract^duration}` . If either the start date or the duration is missing, Clause9 will show a *“missing value”* error. It will be much more friendly to instead invite the user to submit the missing value — which will be the case when you use `{#contract^!start-date + #contract^!duration}` instead. Careful thought must be given to the combination of an “else” block in a (set of) condition(s) and the use of an exclamation mark. In principle, the text behind the “else” block should be shown in case the other condition(s) in the set are not fulfilled. However, the exclamation mark forces the user to assign a value to the relevant datafield. This means that the condition(s) will only be evaluated (and the relevant text shown) after the value has been assigned. As a result, the text in the “else” block will not be shown until a value has been assigned to the relevant datafield. Take this into account as this may, in some cases, not be the behaviour you intended. # Enabled? {% embed url="" %} The enabled? tab in a clause file allows you to set conditions that determine whether or not a clause is shown. This means that, when you insert a clause containing an enabled?-condition, you first need to activate said condition to actually show it (unless the document in which the clause is being inserted already has this condition set to active). {% hint style="info" %} [Documents](/binders/document-and-binder-properties) can also have an enabled?-condition. These work much in the same way as the conditions for clauses. {% endhint %} This is a useful feature for when you want to: * guide users into inserting the right clauses; or * create a template document or questionnaire that can rapidly switch between alternative clauses. The enabled? tab works by simply filling out a condition that will act as the key to showing or hiding that clause. If the condition is met, the clause is shown. If it is not met, the clause is hidden. Since the enabled? tab by definition houses a condition, **it is not necessary to surround it with curly braces**, as you would normally do for conditions that are contained in clauses. It is also not necessary to provide multiple language versions for the condition as the condition contained in the enabled? tab applies to the entire clause either way, regardless of chosen language. {% hint style="danger" %} While it is allowed to use curly braces around the enabled-condition, it is not allowed to use the `{ condition : body text }` structure within the enabled-condition. The reason is that when the condition within such structure is met, the result is some body text component. Having a body text component inside a condition is not allowed, because a condition should only consist of expressions that that are true or false (e.g., “contract value > 100” or “gender = ‘male’ “). From the software’s perspective, including body text inside a condition is similar to asking what color Tuesday is, or how many moons can be found in the number 46. It makes no sense, in other words, hence the error. {% endhint %} You will be able to quickly see whether a clause is subjected to an enabled? condition if you have switched on the “invisible clauses” option under the assemble documents menu contained under the menu on the right-hand side of the Assemble Document screen. Disabled clauses will then be shown as struck through in red. If you select such a clause and then navigate to the *Datafields* tab of your operations panel, you can see which condition(s) is(/are) included in the enabled? tab by selecting clause enablers. For example:
In this example, the clause on the left-hand side is hidden as is evident from the red strike-through lines. Navigating to the datafields tab, we see that a clause enabler condition is active. The question that the condition poses is whether the agent has an exclusive relationship with the principal or not. Since the user has not yet determined whether this is true or false, Clause9 assumes by default that it is false. If we click the grey question bar, thereby indicating that the condition is true, article 1.3 in this document will be shown. Do note that adding this extra layer of drafting protection means that you are burdening your users with an additional hurdle to assembling their contract. You will therefore have to think about striking the right balance between intelligence and usability of the clause. Depending on the overarching strategy your organisation has decided to adopt in utilising Clause9, it could be that adding these conditions complicates things for your users and should therefore only be used in limited circumstances. # Links Documents, binder, clauses and concepts can contain “links”. Links are Clause9's way of making certain types of connections between files. ## What links are used for Links can have any of the following purposes: 1. mark a clause as an alternative, making it easy to switch to an alternative clause in Assemble Document mode by clicking the button next to the clause 2. mark a clause/document/binder as implementing a certain concept, enabling users to use the link as a cross-reference 3. mark a clause/document/binder as containing a definition for a certain concept, thereby making sure the (automatically generated) definition list contains a reference to the relevant clause/document/binder 4. kind of See the video below for a short overview of how to use alternative clauses: {% embed url="" %} ## Search files using links An additional advantage of using links is that – when searching for a clause/document/binder/concept, you can filter based on the link that the relevant file contains. Hit in the search pane to add the link filter. Select the type of link you are looking for in the dropdown list and choose the file that the link is pointing to.
Click and Clause9 will show you all files containing the link you selected. ## How to create links Edit the clause/document/binder/concept of your choosing. Go to the links page by clicking *Links*in the navigation menu on the right.
On this page, you can see an overview of all existing incoming and outgoing links for that file as well as any implicit alternatives based on existing links. ### **Outgoing links** Outgoing links are the links created in the file you are editing. You can create a new (outgoing) link by hitting and choosing the file you want to link to in the browser that pops up. Finally, choose the type of link you wish to create by clicking the dropdown menu in the outgoing link you just created.
### **Incoming links** Incoming links are the mirror image of outgoing links. When another file has created an outgoing link to the file you are viewing, it will be listed as an ‘incoming link’ in the latter file.
Example of an incoming link of a concept being implemented by a clause. {% hint style="info" %} Incoming links can only be edited by editing the outgoing link in the corresponding file. {% endhint %} ## Links & implicit alternatives Under the ‘links’ pane, you can also find implicit alternatives (if there are any). Implicit alternatives are files that contain the same link. They are “implicit” alternatives since there is no explicit “alternative for” type link. However, in view of the fact that the files contain the exact same link to another file, they can be considered to be alternatives implicitly and will be treated as such by Clause9. An example to illustrate: let’s say in your Clause9 library you have two clauses containing a purchase price provision. Both of these clauses contain an “implements” link to the “purchase-price” concept that you created as well. In view of the fact that both of these clauses implement the same concept, Clause9 considers these clauses to be ‘implicit alternatives’. When implementing either of these clauses in a document, you will be shown the icon to switch between the different alternatives. # Cross-references In Microsoft Word, you refer to other clauses by their numbering. In Clause9, how you refer to other clauses will depend on the location of the target — whether this target is located in the same clause file, or whether it is located in some other file. ## Cross-references within the same clause file In the discussions below, the following sample clause is used: {% code overflow="wrap" %} ``` 1. Alpha 2. Beta 2.1 Gamma * Delta * Epsilon * Eta ``` {% endcode %} because of preceding articles in a hypothetical document, that clause happens to render as follows: {% code overflow="wrap" %} ``` X. Alpha XI. Beta A. Gamma i) Delta ii) Epsilon iii) Eta ``` {% endcode %} In the discussions below, we assume that the References Styling for English is set to use *“article”* for referring to clauses. ### **Other numbered sub-clause** To refer to some other numbered sub-clause, you use `§number`*.* For example, to refer to `2. Beta`*,* you would use `§2` . Clause9 will then replace it by a proper cross-reference to that subclause (in the example case *“article XI”*). {% hint style="success" %} If you want to start this reference with a capital (e.g., at the beginning of a sentence), then use special function `@capitalize`. In the example above, `@capitalize(§2)` will result in “Article XI”. {% endhint %} ### **Cross-references between/across internal snippets** It is not possible to refer to numbered sub-clauses across internal snippets. For example, the following will not work:
The reason this does not work, is that each internal snippet can have its own internal numbers, which may perfectly overlap with the numbering of the top-level clause. For example, in the screenshot below, the reference to §1 would be ambiguous if it could also refer to the top-level paragraph.
### **Clause as a whole** In contracts, you frequently refer to the clause itself, e.g. when expressing “*As set forth below in this clause XXX, the Buyer will …”*. To insert such a reference, you use `§this` to refer to the current numbered subclause, and `§this-title` to refer to the encompassing title of the entire clause file (assuming that title is currently visible). For example, if you would insert `§this` within `2. Beta`, the reference would become “*this article XI”.* {% hint style="info" %} Notice the addition of the word this — in French this would for example, depending on the References Styling, become “cette clause XI” or “cet article XI”. Conversely, when you would insert `§this` within `* Delta`, the reference would become “this article 2.1”, because 2.1 is the nearest numbered subclause. {% endhint %} When you insert `§this-title`, Clause9 will refer to the number of the title associated with the clause file. {% hint style="info" %} If that title is not currently visible, an error will appear. {% endhint %} {% hint style="success" %} To capitalise these cross-references, use a capital T. In the example above, `§This` will for example result in *“This article 2.1”*. {% endhint %} ### **Bullets** Within a bullet (asterisks) list, you can refer to the current bullet using `§*`, the next bullet with `§*+` and the previous bullet using `§*-`. {% hint style="info" %} This will only be useful if bullets happen to be styled using iterative numbering such as 1, 2, 3 or a) b), c). If you use symbols that are the same in the entire list (such as a circle or square), Clause9 will rever to literal “the current bullet” or “the next bullet”. {% endhint %} ## Cross-references to clauses outside the clause file {% hint style="info" %} Read our introductory [blog post](https://www.clausebase.com/post/error-reference-source-not-found) on this topic. {% endhint %} ### **Using concepts** Concepts are the most powerful method to refer to clauses outside the current clause file. When using `§#concept`, Clause9 will replace that part of the text with a cross-reference to the first clause that *implements* that clause, i.e. that contains an *implements* link towards that Concept. This is a very powerful mechanism, because it allows you to create cross-references on a *subject-basis* instead of on a numbering-basis (as is the case in Microsoft Word, which causes much more brittle cross-references). Clause9 will even be as helpful to show a list of those clauses that are accessible to the user and implement the specified concept, when no such clause is yet available in the document. {% hint style="info" %} It can also be helpful to check whether some clause is available in the current document that implements a certain clause: the [@implemented special function](/special-functions/concepts#implemented) and its siblings [@implemented-any](/special-functions/concepts#implemented-any) and [@implemented-all](/special-functions/concepts#implemented-all). {% endhint %} ### **Using cross-tags** Using concepts and *§#concept* cross-references is the recommended approach, because it allows you to create a central repository of clauses that implement certain legal subjects. Sometimes, however, the concepts-approach is somewhat burdensome, because it does require you to create a concept for each and every cross-reference you want to establish towards other clause files. If all you want is a simple, one-time cross-reference to some specific clause in your document, it is probably easier to use the so-called *cross-tags*: * Assign some cross-tag (e.g., “liability”) to the target clause, using the *cross-tags* section of the clause. Don’t use any spaces inside a cross-tag. * Insert a cross-reference to that cross-tag in some other clause using `§tag` (e.g. `§liability`). {% hint style="info" %} Similar to `@implemented` for concept-based cross-references, there is also a `@crosstag-implemented` function that returns true when a currently visible clause implements the specified tag. {% endhint %} {% hint style="success" %} To capitalise these cross-references, start them with a capitalised letter. In the example above, `§Liability` will for example result in “Article 2.3” if that article happens to implement tag `liability`. {% endhint %} ## Cross-references to definitions You can insert a cross-reference to the definition of a concept using `§$#concept`. ## Cross-references to other subdocuments Similar to cross-references to other clauses, you can refer to other subdocuments with a hashtag. For example, if some subdocument is specified to implement Concept #pricing, you can refer to this subdocument with `§#pricing`. {% hint style="info" %} Clause9 will insert the short document title (or the long document title if the short one is not available) after the article reference. The actual wording will be determined by the References styling. {% endhint %} ## Relevant styling settings Note that several settings determine the way [references are styled](/styling/references-styling): * the word to use (e.g., in English, *article* vs. *clause* vs. *section*) * how you refer to clauses in other subdocuments (i.e., whether & how the title of that other subdocument should then be shown) * whether to use the title between parentheses after the target article’s number — e.g. *“see article 5 (liability)*“. Note that such part between parentheses will only be inserted if `§#concept` or `§tag` references are used, and if the target clause effectively contains a visible title. # Introduction to tables {% embed url="" %} {% embed url="" %} ## General Tables are collection of **cells**, organised in **rows** (horizontally) and **columns** (vertically). The first row can optionally be assigned the status of a **header row**, which will be repeated on each page if a table spans multiple pages. All the other rows are called **body rows**. In Clause9, a simple table with one header row and is created as follows: {% code overflow="wrap" %} ``` || header 1 || header 2 || header 3 || || ========== || ----------------- || ---------------- || || cell column 1 || cell column 2 || cell column 3 || ``` {% endcode %} This will result in the following table:
A more complex example: {% code overflow="wrap" %} ``` || header 1 || header 2 || header for righ-aligned column || || ------------ || --------------- || ------------------------------: || || cell column 1 || cell column 2 || cell column 3 || ||> merged cell columns 1 & 2 || regular cell || ||>> merged all cells || || regular cell 1 || vertically merged || regular cell 3 || || regular cell 1 ||^ || regular cell 3 || ``` {% endcode %}
Some general notes: * Each cell is separated by a double pipe symbol (||). * Rows are separated by a newline (i.e., pressing Enter). * It is no problem for a row to span multiple lines in the text editor, e.g. because there are too many columns to fit on one line of Clause9's text editor. * You can have maximum one blank line between rows of the same table. If you insert at least two blank lines between rows, then a new table will be started. * It is not necessary to line up the double pipe symbols between lines, although it will of course be much cleaner to like at in the editor. In the .DOCX or .PDF file, this will however not make any difference. * The first row will be treated as a header row if it is followed by a **divider row** that contains cells with either multiple dashes (—-), or multiple equal-signs (====). There should be at least three dashes / equal-signs, but no upper limit applies. * If a column in the divider row contains equal-signs, then all the cells in that column will have a light grey background. In the example above, this is the case for the first column. * Whether the table contains borders, and whether it is left-aligned, center-aligned, right-aligned or instead stretched across the entire width of the page, can be changed in the *base* styling. ## Automatically reformatting a table You can automatically reformat how a table looks inside the Clause9 grammar:
by pressing “reformat tables” in the popup-menu at the right side:
becomes
## Inserting large amounts of text If you want to insert multiple paragraphs into a single cell, you have to use the internal inclusions mechanism. After all, remember that inserting a newline (Enter) would start a new row of the table… Example: {% code overflow="wrap" %} ``` || alpha || beta || gamma || || @DELTA || epsilon || zeta || DELTA = this is a large amount of text... ... spanning multiple paragraphs... ... that will be inserted in the first cell of the second row ``` {% endcode %} results in:
## Alignment of cells The dashes or equal-signs in the divider row can optionally contain a colon (:) before the first dash/equal-sign and/or after the first dash/equal-sign. The presence of these colons will cause all the cells in that column to be left, center or right-aligned, respectively. For example: * `:—--` or `:===` will cause the cells to be left-aligned * `:—--:` or `:===:` will cause the cells to be center-aligned * `---:` or `===:` will cause the cells to be right-aligned * no colon will cause the cells to receive the general alignment specified in the styling (typically left-aligned or justified). ## Merging columns (horizontal cell merging) A cell can optionally span multiple columns. This can be achieved by inserting one or more larger-than symbols (>) immediately after the double pipe (without any space in between). Example: {% code overflow="wrap" %} ``` || alpha || beta || gamma || ||>> delta || epsilon || zeta || eta || ``` {% endcode %} will be outputted as:
## Merging rows (vertical cell merging) A cell can optionally be merged with the cell above it. This can be achieved by inserting a *caret* symbol (^) after the double-pipes. The cell must not contain any other content. Example: {% code overflow="wrap" %} ``` || alpha || beta || gamma || ||^ || delta || epsilon || ``` {% endcode %} will be outputted as:
Note that horizontal and vertical merging can be combined. The cell that contains the caret will then have the same horizontal merging amount as the above cell it is merged with. Example: {% code overflow="wrap" %} ``` || alpha || beta || gamma || ||> delta || epsilon || ||^ || zeta || ``` {% endcode %} will be outputted as:
## Conditional rows Each body row can optionally contain a condition that will determine whether or not the row will be shown. This condition can be any valid condition, needs to be surrounded by curly brackets, and needs to be inserted after the last set of double-pipes. For example: Example: {% code overflow="wrap" %} ``` || alpha || beta || || ---- || ---- || || gamma || delta || {#deal^value > 5000 EUR} || epsilon || zeta || {#deal^value <= 5000 EUR} ``` {% endcode %} In this example, the row with cells *gamma* and *delta* will only be shown if the *#deal^value* data-field happens to be larger than 5000 EUR. If not, the row with *epsilon* and *zeta* will be shown. ## Conditional columns Similar to rows, columns can also be made conditional, by inserting a condition in curly brackets on the first row of the table. For example: {% code overflow="wrap" %} ``` || {#deal^value > 5000 EUR} || || || alpha || beta || || ---- || ---- || || gamma || delta || || epsilon || zeta || ``` {% endcode %} The first column will not be shown if the *#deal^value* data-field contains a value lower than 5000 EUR. ## Repeating rows A row will be automatically repeated if it contains at least one *repeating* data-field (hence the name of this type of data-field). The row will then be repeated for as many times as there are values in the repeating data-field. (If multiple repeating data-fields are used, then the repetition-amount will be equal to the amount of the repeating data-field with the largest amount of repeating data-fields) For example, assume that the *#item^name, #item^price* and *#item^quantity* data-fields are all repeating-fields, containing the following values: * *#item^name*: alpha, beta, gamma and delta * *#item^price:* 100 EUR, 200 EUR, 300 EUR and 400 EUR * *#item^quantity:* 1, 2 and 3. The following table: {% code overflow="wrap" %} ``` || name || price || quantity || || ==== || ----- || -------------- || || #item^name || #item^price || #item^quantity || ``` {% endcode %} will then result in the following output:
Notice that the quantity of delta is not filled in, because the #item^quantity data-field only contained three items. {% hint style="danger" %} Do not use repeating fields from multiple concepts in the same row, as this is ambiguous (you will get an error message about “multiple repeating-lists in the same row”). After all, which of the concepts data should then be used to calculate the number of rows? {% endhint %} ## Layout settings In the “Table Settings” of the [Base styling](/styling/base-styling) (which you can always add to a specific clause through the [custom styling](/files/custom-styling) option) you can specify various options for tables, such as a table’s alignment, width, borders, background and text flow. # Deviating table styling ## Deviating styling If you want a table to deviate from the styling settings applied at a higher level (e.g., the level of a clause, document, or user defaults), you can insert an optional very first row, in which the only cell contains one or more (each separated by a comma) of the settings listed in this article between *% … %*. {% hint style="info" %} – *unit* can be either *0* (zero — to remove something), *cm* (centimers), *mm* (millimeters), *i* (inch), *pt* (points, the typical measurement unit for fonts) or *px* (pixels, the typical measurement unit for images on screen); – *hex* refers to the CSS hex format, which is a combination of either 3 or 6 hex characters (a number or a / b / c / d / e). For example, #FF0000 is pure red, while #22B61E is a green variant. There are numerous websites and software programs that can help you find the right color — see for example or {% endhint %} {% hint style="info" %} To be clear: the deviating styling row should be the very first row, and should only contain a single cell. If you add more cells, Clause9 will get confused, or consider the row to be a regular row. {% endhint %} ## **General** * **align left, align right, align center** or **align full width —** set the alignment * *align left, align center* and *align right* can be followed by a number between 1 and 100 to set the relative width vis-à-vis the page (e.g., *align right 30* results in a right-aligned table of 30% page width) * **background #hex —** sets the background of the table — i.e., every cell but the cells of the header row and header columns — to the specified color * for example, *background #00ff00* would set the background color of those cells to pure green * **borders amount unit —** sets the width of the outside borders * for example, *borders 5px* sets the four outside borders to 5 pixels * **borders #hex —** sets the color of the outside borders to the specified hex color * for example, *borders #aabbcc* would set the colors of the outside borders to blueish gray * **borders true** and **borders false** enables or disables the outside borders * **borders horizontal/vertical amount unit —** sets the width of either the horizontal lines between each row or the vertical lines between the columns * for example, *borders horizontal 1mm* would set each inside horizontal line to 1 millimeter * *borders vertical 0* would remove the inside vertical lines * **borders horizontal/vertical #hex —** sets the color of either the horizontal lines between each row or the vertical lines between the columns * for example, *borders vertical #fff* would set each inside vertical line to white * **cell padding left/right/top/bottom** — sets the inner padding for each cell * **distribution auto** — results in a table with an automatic width, determined to fit its contents * **distribution evenly** — results in a table where all the columns have an equal width * **distribution 10, distribution 20, distribution 30** or **distribution 50 —** results in a table where the first column has the specified relative width percentage, while all the other columns equally share the rest of the available space * for example, *distribution 10* in a table with four columns would result in a table where the first column has 10% of the width, while the second, third and fourth column would each have 30% of the width * **distribution x/y/z… —** results in a table where the first column has width x%, the second column relative width y%, the third column relative width z% etc. * for example, *distribution 20/30/40/50* results in a table where the first column has 20% width, the second 30%, the third 40% and the fourth 50% * **header background #hex —** sets the background-color of the header rows and header columns (i.e., columns for which a ======= was inserted in the divider row) * for example, *header background #aaa* would set the header background to medium gray * **indent** — sets the table’s left indent amount (relative to the indent type described below, e.g. calculated from the paper’s left margin or the previous heading’s left margin) * **indent from left side** — sets the table’s left indent type to the paper’s left margin * **indent from heading** — sets the table’s left indent type to the preceding heading’s left side * **indent from heading** **text** — sets the table’s left indent type to the preceding heading’s text position (i.e., after the heading’s number, if any) * **indent from body** — sets the table’s left indent type to the preceding body paragraph’s left side * **indent from body** **text** — sets the table’s left indent type to the preceding body paragraph’s text position (i.ie., after the body’s bullet, if any) * **indent from paragraph** — sets the table’s left indent type to the preceding paragraph’s left side (which can be either a heading or a body paragraph) * **indent from paragraph** **text** — sets the table’s left indent type to the preceding paragraph’s text position (i.e., after the number of bullet) * **width x —** sets the width of the table relative to the page * for example, *width 30* sets the width to 30% of the page width ## **Multi-cell styling** Clause9 also allows you specify the styling of several cells at once, by specifying a *location* and a *styling*. The **locations** can be any of the following: * **top left cell**, **top right cell**, **bottom left cell** and **bottom right cell** * **first row** refers to all the cells of the top row * **last row** refers to all the cells of the last row * **first column** refers to all the cells of the leftmost column of the table * **last column** refers to all the cells of the rightmost column of the table * **odd rows** refers to all the cells of every odd row (i.e., the first row, third row, fifth row, etc.) * **even rows** refers to all the cells of every even row (i.e., the second, fourth, sixth, etc. row) * **odd columns** refers to all the cells of every odd column (i.e., the first, third, fifth columns, etc.) * **even columns** refers to all the cells of every even column (i.e., the second, fourth, sixth, etc. column) The **styling** can be any of the following: * **italic true / false** sets the style to italic (you can also leave out the true, it is implied) * **bold true / false** sets the style to bold (you can also leave out the true, it is implied) * **underline true / false** sets the style to underlined (you can also leave out the true, it is implied) * **font #hex** sets the font color * **font *****font-name*** sets the font family (font-name can be either Arial, Arial Black, Arial Narrow, Cambria, Calibri, Courier, Georgia, Gill Sans, Impact, Palatino, Tahoma, Times, Trebuchet or Verdana) * **background #hex** sets the background-color of each cell * **border left/right/top/bottom #hex** sets the color of the specified border, while **border #hex** sets the color of all four borders at once * **border left/right/top/bottom amount unit** sets the width of the specified border, while **border amount unit** sets the width of all four borders at once * **borders horizontal/vertical #hex** sets the color of either the horizontal lines between each row, or the vertical lines between each column * **borders horizontal/vertical amount unit** sets the width of either the horizontal lines between each row, or the vertical lines between each column {% hint style="info" %} For the first/last/even/odd columns, the top border refers to the single line at the top of the first cell in the column, while the bottom border refers to the single line at the bottom of the last cell of the column. If you wan to refer to the lines at the top and bottom of every other cell in the column, you have to refer to the borders horizontal. Similarly, the border left/right of first / last / even / odd rows refers to the single lines at the left and right of respectively the leftmost and rightmost cell, while the borders vertical refer to the left/right of every other cell of the row. {% endhint %} ## **Examples** The following code sets the first row to bold, not underlined, with a red background and white letters: (The *underline false* is only relevant if some other styling setting with less precedence — e.g., the default styling of the company — would specify underlining by default. {% code overflow="wrap" %} ``` || % first row bold true, first row underline false, first row font #fff, first row background #ff0000 % || || Example row 1, cell 1 || Example row 1, cell 2 || || Example row 2, cell 1 || Example row 2, cell 2 || ``` {% endcode %}
The following code sets the width of the left border of the top row to 4mm and ensures at the same time that all the cells of the last row will have a red background: {% code overflow="wrap" %} ``` || % first row border left 4mm, last row background #ff0000 % || || Example row 1, cell 1 || Example row 1, cell 2 || || Example row 2, cell 1 || Example row 2, cell 2 || ``` {% endcode %}
{% hint style="info" %} Some combinations of instructions will be conflicting. For example, specifying that the cells of the first row should have a yellow background, while at the same time specifying that the cells of the first column should have a red background, raises the question which color the top left cell should get. The answer is that locations mentioned earlier in the bullet-list above (in casu the first row) will have precedence. {% endhint %} # Shrinking clauses ## Introduction When a part of a paragraph is wrapped in `@superfluous`, users of the clause can shrink down the clause with the *Shrink or expand text* button of the menu in the upper right corner, in order to hide that wrapped part.
Example: ``` Supplier will @superfluous(1, "acknowledge and") agree that timing is of the essence. ``` When **no shrinking** is applied, the existence of the special function will simply be ignored, and this clause will be shown in full: *The Supplier will acknowledge and agree that timing is of the essence.* However, when **full shrinking** is applied, the part within the special function will be dropped: *The Supplier will agree that timing is of the essence.* ## Details #### Shrinking opportunity indicators In the actual document (left side) of Assemble Documents, it is possible to show green indicators, by enabling *“clause shrinking opportunities”* in the options button at the right side of the toolbar. By default, these indicators are not shown. ### Use cases The typical use case of the clause shrinking feature is to hide text that can be assumed to add relatively little legal content to a paragraph. This may, for example, be the case with: * sentences that are inserted *“for the avoidance of doubt”* * synonyms of words that are mainly inserted because of legal tradition * text for which all the words may be mandatory / recommended under a certain jurisdiction, but that would be considered extraneous in other jurisdictions (e.g., under many continental European law systems, *“acknowledge and agree”* instead of simply *“agree”*) This way, you can create alternative versions of a single clause, without having to create separate “light”, “medium”, “strong” versions. Similarly, while datafields can be used to achieve similar effects (and much more), they require more effort to insert. ### Nesting of square brackets Clause9 currently allows up to four levels of nested superfluousness-text. Shrinking level 1 will discard any text within the `@superfluous` call, while shrinking level 2 will also show the text within the first call, and shrinking level 3 will also show the text within the second (i.e., inner) call. And so on. {% hint style="info" %} If you want to nest multiple square brackets, you must use [internal snippets](/clauses/snippets). {% endhint %} By way of example:
This will result in the following possible paragraphs: * **Shrinking level 1** — The Supplier will agree that timing is of the essence. * **Shrinking level 2** — The Supplier will *acknowledge and* agree that timing is of the essence. * **Shrinking level 3** — The Supplier will *explicitly* acknowledge and agree that timing is of the essence. * **Shrinking level 4** — The Supplier will explicitly *and before the commencement date* acknowledge and agree that timing is of the essence. * **Full text** — The Supplier will explicitly and*, if so requested by the Client,* before the commencement date acknowledge and agree that timing is of the essence. ### Inheriting the shrinking levels The shrinking level applies to all clauses within a clause file. However, to allow a shrinking level to be applied to many clauses at once, the shrinking levels are *inherited* between clause files, except if a descendant would define its own shrinking level. For example, assume that in the following example the five clauses (Alpha, Beta, Gamma, Delta and Epsilon) are all stored in separate files.
Assume that Alpha is set to shrinking level 1. Then both Beta and Gamma will *inherit* this shrinking level (because they are the *descendants* of Alpha), and will thus also show their text at shrinking level 1. Delta, on the other hand, is a *sibling* of Alpha, and will therefore not inherit the shrinking level of Alpha. The same applies to Epsilon. Now assume that Beta is set to level 3. This will cause its descendant Gamma to also show its text at level 3, except if Gamma would define its own level. Note that changing the level of Beta or Gamma will never impact Alpha, Delta or Epsilon. ### Shrinking an entire document If no clause is selected when changing the shrinking level, then the shrinking level of the entire document will be set. Note that the document acts as an *ancestor* of all clauses, so that — except if some clause (or one of its ascendants) would define its own shrinking level — all clauses will inherit the shrinking level of the Document. This allows you to quickly “compress” a document. ## Usage tips Avoid superflousness-calls at the beginning of a sentence: if such part would get omitted, then the remaining part of the sentence would be shown without a capital. Be aware that, if several sets of square brackets would be used in a single clause file, all of those sets will show and omit their text in lockstep. # Action buttons {% embed url="" %} Action buttons are a good way of making a clause more user friendly in documents. They can have three functions: * execute a saved search * browse a folder of your choosing * present preselected clauses This way, when the clause with the action button was included in a document, the action button gives the user a shortcut to add further relevant (sub)clauses to the document. ## Adding an action button to a clause Start editing a clause (either in the *Browse Files* mode or in *Assemble Document*). In the navigation menu on the right, go to *Action Button*.
Click . * **button caption** — Create a caption for the button (i.e. the text that will be visible on the button), optionally in multiple languages. * **button position — Where the button should be positioned relative to this clause’s subclauses.** * **hide button when — The button can optionally be hidden when at least one subclause exists.** * **action** — Choose one of the three options described above. ## Tips for using action buttons * Action buttons are especially suited for use when a clause can have several optional subclauses. * When there is a high number of optional subclauses, it is preferable to use the option to browse to a folder. The contents of that folder can be easily managed (by removing or adding clauses to it) as well. # Enumerations {% embed url="" %} Enumerations (French: *énumération* / Dutch: *opsomming /* German: *Aufzähung*) are used to create lists of items. Depending on the applicable [styling settings for enumerations](/styling/enumerations-styling) and the content of each item, those items will then be formatted either as an “inline” list of items, or as a bullet-list, as shown in the next example:
## Why use enumerations? You may wonder why you would want to use the special enumeration code, instead of manually typing in the items. The benefits of using the special codes include: * **The formatting will be automatically determined**, through a combination of the length of each item and the applicable [styling settings for enumerations](/styling/enumerations-styling). Without having to change legal content, you will be able to accommodate both users who want a traditional list of romanette items — *(i) … (ii) … (iii) …* — and users who want a more modern, bullet-style list. * **You will never have to worry again about numbering**: Clause9 will automatically ensure that the right numbers are inserted, sequentially, without any gaps or duplicates. If a certain item is subjected to a condition that happens not to be fulfilled, then that item will not be shown, and all numbers following it will be adapted accordingly. * **Suffixes are automatically inserted**: depending on the chosen [styling settings for enumerations](/styling/enumerations-styling) and the type of list, a semicolon, full stop (.), &, “and”, “or”, or “and/or” will be inserted. ## Grammar The basic structure of an enumeration is as follows: `{ AND | item1 | item2 | item3 }` ### **Enumeration type** Right after the opening accolade you have to choose the type of enumeration — ***AND*****,** ***OR*****,** ***AND/OR*** or ***LIST***. This will respectively result in a list that uses suffix “and”, suffix “or”, suffix “and/or”, or no suffix at all after the item(s). {% hint style="info" %} Whether this suffix is actually repeated after each item, or instead only after the penultimate item, depends on the [enumeration styling settings](/styling/enumerations-styling). {% endhint %} ### **Skipping the final suffix** You can also choose **AND-SKIPFINAL**, **OR-SKIPFINAL**, **AND/OR-SKIPFINAL** or **LIST-SKIPFINAL** as the enumeration type. If the enumeration happens to get outputted as a bullet-list, then the final item will not get a suffix. The example above (if it would happen to get printed as a bullet-list) would then look as follows:
### **Enforcing bullets** In principle, whether an enumeration is printed inline or as bullets, depends on the applicable [styling settings for enumerations](/styling/enumerations-styling). However, you can force an enumeration to always be printed as bullets — so irrespective of the layout-settings — by adding an exclamation-mark after the list type. For example: `{ AND! | item1 | item2 | item3 }` `{ AND-SKIPFINAL! | item1 | item2 | item3 }` ### **Item separators** Each item should be separated by the pipe symbol ( | ). ### **Optional item number** Right after the pipe symbol, you can optionally insert a number. If the enumeration then happens to get printed as an inline list, each item of the enumeration will be preceded by a sequential number. For example: `{ OR | 1. alpha | 2. beta | 3. gamma }` as an inline list, this will result in the following output (assuming that romanettes are chosen in the styling settings for enumerations): *(i) alpha, (ii) beta; and (iii) gamma* {% hint style="info" %} Including the optional number will have no effect if the enumeration gets printed as a bullet-list. {% endhint %} {% hint style="info" %} The actual numbers that are typed in, do not matter much — whether you nicely type in 1., 2. and 3., or instead a non-sensical sequence such as 45., 9. and 333., does not matter.\ In the future, Clause9 may use the actual number to allow you to cross-reference other items, but such functionality is not yet enabled. {% endhint %} ### **Using conditionals** If you subject the content of an item to a condition, then the item may get skipped, depending on whether the condition is fulfilled. Clause9 will automatically ensure that the right numbering is used. For example: `{AND | 1. {#employee^gender = "male": alpha } | 2. beta | 3. gamma }` If *#employee^gender* happens to be **false**, then the enumeration would be shown as follows (assuming that the styling settings allow for an inline list): *(i) alpha; (ii) beta; and (iii) beta* If, instead, *#employee^gender* happens to be **true**, then the enumeration would get printed as follows: *(i) beta; and (ii) beta* ## Using special functions Enumerations can also be created using one of the following special function calls: * [@enumerate](/special-functions/text-structure#enumerate) — taking as a parameter a list. Whether the enumeration is printed inline or as bullets, depends on the styling settings and the contents of the items. * [@bullets](/special-functions/text-structure#bullets) — like @enumerations, but always prints the enumeration as a bulleted list, similar to using an exclamation mark after the list type Both special functions have some variations (see `@bullets-and,` `@enumerate-numbered`, etc.)— see the detailed explanations for both functions. Using these special functions is most useful when the items you want to print, happen to be stored in a datafield. For example, if *#employee^items-to-return* is a datafield that contains a list of items to be returned, then [`@enumerate-numbered-and`](/special-functions/text-structure#enumerate) would print such list as follows (assuming that inline printing applies per the styling settings): *(i) key card; (ii) confidential documents; (iii) car; and (iv) car keys.* ## Forcing \* bullets into an enumerated list If your clause should contain actual bullets (i.e. with asterisks), you can still [force the bullets into an enumerated list](https://help.clause9.com/clauses/clause-structure#forcing-enumeration-with-and-or-or) by inserting `* AND` or `* OR` as the very first bullet. For example: ``` 1. This list will be shown with an "and" before the final item: * AND * apple * banana * cucumber ``` # File position “Position” is one of the properties of clause files. It can be used to suggest the appropriate positioning of a clause to users of the clause. {% hint style="info" %} An example of good use of preferred positioning of a clause is a clause containing a signature block, which should in most cases be positioned at the very end of a document. {% endhint %} ## How ‘position’ works A clause can be assigned an (approximate) preferred position within a document. Five types of preferred positions are possible: * at the very beginning of a document * towards the beginning * somewhere in the middel * towards the end * at the very end When a preferred position has been assigned to a clause, a user wanting to insert that clause in his/her document will be able to choose “automatic position” instead of the standard options for inserting clauses.
“Automatic position” will be suggested when inserting a clause with a preferred position. ## How to assign a preferred position to a clause When editing a clause, navigate to *Position* in the navigation menu on the right hand side. You can now select one of the five options listed above for your clause.
Dropdown list to choose a preferred position. If you want the clause to no longer have a preferred position, pick choose “N/A”. Hit to save your changes. # Snippets Snippets are ways of making writing new clauses more efficient and/or more readable. They are re-usable pieces of text that can either be used inside one clause (internal snippets) or as part of all clauses (external snippets). Snippets work similar to variables in mathematics or programming languages. They are referenced by a name and represent a piece of text. ## Internal snippets {% embed url="" %} Internal snippets are pieces of text that can be used multiple times **inside the same clause**. They will not be available outside the clause where they are defined. Internal snippets are defined at the bottom of a clause as follows: `NAME-SNIPPET = content snippet`. Insert the name by which you want to refer to the snippet in all caps, e.g. NAME-SNIPPET. Then, after the equals symbol (`=`), insert the text you want to be inserted in all places where the snippet is referenced. Referring to an internal snippet (i.e. showing Clause9 where the snippet text should be placed) is done by taking the name of the snippet and adding an “at” symbol `@`. For example: {% code overflow="wrap" %} ``` 1. This is @SNIPPET. SNIPPET = a snippet, which will be replaced by the text defined at the bottom of the clause grammar ``` {% endcode %} Will result in the following:
Snippets may contain all types of text, datafields or conditions. They can even refer to other (internal or external) snippets, making multi-tiered snippets possible. {% hint style="danger" %} Always leave **at least** one blank line between each definition of an internal snippet. {% endhint %} ### External snippets External snippets are similar to internal snippets. They are, however, defined and referenced differently. #### **Defining an external snippet** Because an external snippet should be made available to all clauses inside your library, it should be **defined** outside a normal clause. It is defined by creating a normal clause which will be used as a kind of special purpose vehicle. Naming an external snippet follows the same rules as the naming of [a concept](/concepts/introduction-to-concepts). The file name of the clause that will serve as an external snippet may, e.g., not contain any spaces as that would make referring to the external snippet impossible (see below). It is not necessary to use all caps when naming an external snippet. Enter the text for your snippet as the clause’s content body. #### **Referring to an external snippet** While internal snippets are referenced by simply adding a `@`-prefix, external snippets are referenced differently. After the `@`, a hashtag has to be added as well: `@#`. For example: `@#external-snippet`. ## Purposes ### Efficiency and consistency Snippets can make writing clauses more efficient and consistent. Using snippets, you can easily create a piece of text that is used in many spots at once. This also saves time when that piece of text must be changed or updated: just change the snippet and all places where that snippet is referenced will automatically incorporate that change (which is much the same way a library clause functions). ### Readability A snippet can also make reading clause grammar more easy. For example, conditional text may become very complex if multiple conditions have to be evaluated at the same time. Long/complex grammar may make the structure of the clause grammar difficult to read. Replacing the most complex bits of grammar with snippets will improve readability. ## Bonus tip: snippets within snippets This may not be obvious at first sight, but you can actually use snippets within snippets, any level deep. For example, you can write: {% code overflow="wrap" %} ``` #Buyer shall purchase @GOODS-OR-SERVICES from #seller. GOODS-OR-SERVICES = {#contract^goods-sold = true: @GOODS | #contract^services-sold: @SERVICES} GOODS = #goods in perfect condition, at @GOODS-PRICE, GOODS-PRICE = {#goods^price > 500 EUR: the extremely low price of #goods^price | else: the price of #goods^price} SERVICES = #services that meet the specified criteria ``` {% endcode %} From a mental point of view, all these snippets facilitate easier reading, because you don’t have to nest conditions and curly braces, which becomes difficult to keep track of as from the second level deep. {% hint style="danger" %} Although you can go any level deep, you should be aware not to introduce circular references between snippets — e.g., snippet @A incorporating snippet @B, while snippet @B incorporates @C, and @C on its turn incorporates @A. This last part would cause an endless cycle that will cause an error. {% endhint %} ## Example The following grammar is rather difficult to read: {% code overflow="wrap" %} ``` 1. <#Seller> shall use best efforts to satisfy or procure the satisfaction of #conditions-precedent in {AND | {"cp-change-of-control" in #conditions-precedent^!seller-responsibility: §cp-change-of-control} | {"cp-competition-clearance" in #conditions-precedent^seller-responsibility: §cp-competition-clearance} | {"cp-financing" in #conditions-precedent^seller-responsibility: §cp-financing} | {"cp-security-release" in #conditions-precedent^seller-responsibility: §cp-security-release} | {"cp-waiver-first-refusal" in #conditions-precedent^seller-responsibility: §cp-waiver-first-refusal}} as soon as [reasonably] possible. 2. <#Purchaser> shall use best efforts to satisfy or procure the satisfaction of #conditions-precedent in {AND | {"cp-change-of-control" in #conditions-precedent^!purchaser-responsibility: §cp-change-of-control} | {"cp-competition-clearance" in #conditions-precedent^purchaser-responsibility: §cp-competition-clearance} | {"cp-financing" in #conditions-precedent^purchaser-responsibility: §cp-financing} | {"cp-security-release" in #conditions-precedent^purchaser-responsibility: §cp-security-release} | {"cp-waiver-first-refusal" in #conditions-precedent^purchaser-responsibility: §cp-waiver-first-refusal}} as soon as [reasonably] possible. 3. Each @singular(#-parties) shall notify the other @singular(#-parties) as soon as it becomes aware that @singular(#?conditions-precedent) has been satisfied. ``` {% endcode %} Using internal snippets, we can improve this grammar: {% code overflow="wrap" %} ``` 1. <#Seller> shall use best efforts to satisfy or procure the satisfaction of #conditions-precedent in @CPS-SELLER as soon as [reasonably] possible. 2. <#Purchaser> shall use best efforts to satisfy or procure the satisfaction of #conditions-precedent in @CPS-PURCHASER as soon as [reasonably] possible. 3. Each @singular(#-parties) shall notify the other @singular(#-parties) as soon as it becomes aware that @singular(#?conditions-precedent) has been satisfied. CPS-SELLER = {AND | {"cp-change-of-control" in #conditions-precedent^!seller-responsibility: §cp-change-of-control} | {"cp-competition-clearance" in #conditions-precedent^seller-responsibility: §cp-competition-clearance} | {"cp-financing" in #conditions-precedent^seller-responsibility: §cp-financing} | {"cp-security-release" in #conditions-precedent^seller-responsibility: §cp-security-release} | {"cp-waiver-first-refusal" in #conditions-precedent^seller-responsibility: §cp-waiver-first-refusal}} CPS-PURCHASER = {AND | {"cp-change-of-control" in #conditions-precedent^!purchaser-responsibility: §cp-change-of-control} | {"cp-competition-clearance" in #conditions-precedent^purchaser-responsibility: §cp-competition-clearance} | {"cp-financing" in #conditions-precedent^purchaser-responsibility: §cp-financing} | {"cp-security-release" in #conditions-precedent^purchaser-responsibility: §cp-security-release} | {"cp-waiver-first-refusal" in #conditions-precedent^purchaser-responsibility: §cp-waiver-first-refusal}} ``` {% endcode %} Alternatively, using external snippets, we would have the following three clauses: {% code overflow="wrap" %} ``` 1. <#Seller> shall use best efforts to satisfy or procure the satisfaction of #conditions-precedent in @#cps-seller as soon as [reasonably] possible. 2. <#Purchaser> shall use best efforts to satisfy or procure the satisfaction of #conditions-precedent in @#cps-purchaser as soon as [reasonably] possible. 3. Each @singular(#-parties) shall notify the other @singular(#-parties) as soon as it becomes aware that @singular(#?conditions-precedent) has been satisfied. ``` {% endcode %} A snippet called *cps-seller*: {% code overflow="wrap" %} ``` {AND | {"cp-change-of-control" in #conditions-precedent^!seller-responsibility: §cp-change-of-control} | {"cp-competition-clearance" in #conditions-precedent^seller-responsibility: §cp-competition-clearance} | {"cp-financing" in #conditions-precedent^seller-responsibility: §cp-financing} | {"cp-security-release" in #conditions-precedent^seller-responsibility: §cp-security-release} | {"cp-waiver-first-refusal" in #conditions-precedent^seller-responsibility: §cp-waiver-first-refusal}} ``` {% endcode %} And a snippet called *cps-purchaser*: {% code overflow="wrap" %} ``` {AND | {"cp-change-of-control" in #conditions-precedent^!purchaser-responsibility: §cp-change-of-control} | {"cp-competition-clearance" in #conditions-precedent^purchaser-responsibility: §cp-competition-clearance} | {"cp-financing" in #conditions-precedent^purchaser-responsibility: §cp-financing} | {"cp-security-release" in #conditions-precedent^purchaser-responsibility: §cp-security-release} | {"cp-waiver-first-refusal" in #conditions-precedent^purchaser-responsibility: §cp-waiver-first-refusal}} ``` {% endcode %} These final two external snippets can be used in other clauses as well by using the references `@#cps-seller` and `@#cps-purchaser`. ## Using snippets to reuse values While most snippets will contain text, it is also possible to use snippets as containers for data-values and calculations. For example: {% code overflow="wrap" %} ``` 1. Buyer will pay an amount equal to @INTEREST before 1st January. If this payment is not successfully performed, it will be automatically increased to {@INTEREST * 2}. INTEREST = (100 + #contract^minimum-interest-base + (#contract^value * 0.05)) ``` {% endcode %} Instead of repeating the fairly complex interest-calculation all over the contract, you can store it in an (internal or external) snippet and reuse it. Note: When storing a value or calculation in an *external* snippet, you should wrap it in curly braces `{ ... }` to avoid that the contents of the snippet would be treated as clause text. (As explained in [Mixing Data Types](/clauses/mixing-data-types), clause text cannot be used to perform calculations.) {% hint style="info" %} The underlying reason is that Clause9 will first to treat internal snippets as a calculation or condition. Only when that fails, it will treat the internal snippet as mere text. Accordingly, in an internal snippet, it is not necessary to wrap a value or calculation in curly braces. The reverse is true for the main body of a clause, where Clause9 will treat contents as text, except when put between curly brackets. {% endhint %} ## Using (internal) snippets to reuse conditions Internal snippets cannot only store values and expressions, but also *conditions*. For example, instead of repeating the same logic over and over again: {% code overflow="wrap" %} ``` 1. {#contract^value > 6000 EUR AND #contract^jurisdiction = "dutch": For high-value contracts under Dutch law, #Seller shall provide the following exception ...} 2. If #Buyer purchases more than {#contract^value > 6000 EUR AND #contract^jurisdiction = "dutch": 300 | else: 600} items, then ... ``` {% endcode %} …. you can store the condition in an internal snippet, and reuse it everywhere, thereby increasing readability and consistency: {% code overflow="wrap" %} ``` 1. {@HIGH-VALUE-DUTCH: For high-value contracts under Dutch law, #Seller shall provide the following exception ...} 2. If #Buyer purchases more than {@HIGH-VALUE-DUTCH: 300 | else: 600} items, then ... HIGH-VALUE-DUTCH = #contract^value > 6000 EUR AND #contract^jurisdiction = "dutch" ``` {% endcode %} {% hint style="info" %} It is not possible to use *external* snippets for storing conditions. If you want to reuse conditions across clauses, you can however use [data-expressions](/datafields/data-expressions). {% endhint %} ## Using snippets to perform if/then/else switches within another calculation Sometimes it is useful to switch between values in the middle of a calculation. For example, assume that in a certain contract the price of the tomatoes that are sold, depends on the country, the weather and the volume: *price = base-price \* country-factor \* weather-factor \* volume* If, for example, there are 4 possible countries (NL / FR / DE / UK) and 3 possible weather-conditions (dry / humid / stormy), you would end up with a huge number of if/then/else parts: {% code overflow="wrap" %} ``` The agreed price is equal to: { #country^name = "nl" AND #weather^condition = "dry": #contract^base-price * 1.1 * 2.1 * #contract^volume | #country^name = "nl" AND #weather^condition = "humid": #contract^base-price * 1.1 * 2.3 * #contract^volume | #country^name = "nl" AND #weather^condition = "stormy": #contract^base-price * 1.1 * 2.5 * #contract^volume | #country^name = "fr" AND #weather^condition = "dry": #contract^base-price * 1.5 * 2.1 * #contract^volume | #country^name = "fr" AND #weather^condition = "humid": #contract^base-price * 1.5 * 2.3 * #contract^volume | #country^name = "fr" AND #weather^condition = "stormy": #contract^base-price * 1.5 * 2.5 * #contract^volume | and so on for the other two countries} ``` {% endcode %} In such situations, it is much cleaner to use the following: {% code overflow="wrap" %} ``` The agreed price is equal to: { #contract^base-price * @COUNTRY * @WEATHER * #contract^volume } COUNTRY = {#country^name = "nl": {1.1} | "fr": {1.5} | "de": {1.8} | "uk": {1.2}} WEATHER = {#weather^condition = "dry": {2.1} | "humid": {2.3} | "stormy": {2.4}} ``` {% endcode %} {% hint style="info" %} Note that you have to wrap the numbers within curly braces, otherwise they would be treated as text (see the [Mixing Data Types page](/clauses/mixing-data-types) for an explanation), so that an error would be produced. {% endhint %} {% hint style="success" %} Another possibility is to use the `@switch` special function. However, when the amount of cases gets high, it is probably cleaner to split calculations in several parts, using the if/then/else constructs above. {% endhint %} ## Snippets with parameters ### Introduction For even greater reuse of text blocks, you can optionally use *placeholders (*called 'parameters') in both internal and external snippets. For legal experts who are first confronted with this idea, this will seem like a far-fetched idea. However, its usefulness should quickly become clear with the use of some examples. Assume that you have a datafield `#employee^gender` that can either contain `"female"` or `"male"` as a value. In your paragraphs, you want to alternate between “Mr.” and “Mrs.”, depending on the gender. This is of course very easy: {% code overflow="wrap" %} ``` ... and {#employee^gender = "female": Mrs. | else: Mr.} #employee^last-name shall be obliged to ... ``` {% endcode %} Let’s make this a little bit more complex. Assume that you not only have `#employee^gender`, but also `#manager^gender` and `#consultant^gender`, and you also want to alternate between “Mr”. and “Mrs.” for these datafields: {% code overflow="wrap" %} ``` ... and {#employee^gender = "female": Mrs. | else: Mr.} #employee^last-name shall be obliged to do X, as supervised by {#manager^gender = "female": Mrs. | else: Mr.} #manager^last-name and assisted by {#consultant^gender = "female": Mrs. | else: Mr.} #consultant^last-name ``` {% endcode %} This is still easy, but quickly becomes quite verbose, with a lot of repetition. The structure of the three conditions is actually identical, the only difference is the datafield that is being referenced. ### Using a single placeholder To avoid this repetitiveness, you can use placeholders within a snippet: {% code overflow="wrap" %} ``` ... and @MR-MRS(?GENDER := #employee^gender) #employee^last-name shall be obliged to do X, as supervised by @MR-MRS(?GENDER := #manager^gender) #manager^last-name and assisted by @MR-MRS(?GENDER := #consultant^gender) #consultant^last-name MR-MRS = {?GENDER = "female": Mrs. | else: Mr.} ``` {% endcode %} As you know by now, the software will replace each reference to `@MR-MRS`, by the contents of the snippet. If you also specify one or more *placeholders* between parentheses, then the software will additionally replace each placeholder with the specified content. For example, `@MR-MRS(?GENDER := #employee^gender)` will be converted into `{#employee^gender = "female": Mrs. | else: Mr.}`, because the `?GENDER` placeholder within the snippet is being replaced with the value #employee^gender. As a result, you can use the very same snippet for three different datafields, by having the software swap the placeholder. ### Using multiple placeholders You can also use multiple placeholders for snippets. For example, let’s also include the last name in the snippet: {% code overflow="wrap" %} ``` ... and @MR-MRS(?GENDER := #employee^gender, ?NAME := #employee^last-name) shall be obliged to do X, as supervised by @MR-MRS(?GENDER := #manager^gender, ?NAME := #manager^last-name) and assisted by @MR-MRS(?GENDER := #consultant^gender, ?NAME := #consultant^last-name) MR-MRS = {?GENDER = "female": Mrs. | else: Mr.} ?NAME ``` {% endcode %} In this short paragraph, this may not seem like a huge advantage. However, from a maintenance perspective — particularly when using *external* snippets — this is a significant improvement, because the way that a person’s title and name are being represented, can then be centrally organised. If ever you want to change the way persons are inserted in the documents (e.g., a new corporate policy would require to say “MR. SMITH” instead of “Mr. Smith”) then you only have to change one small piece of text, instead of having to “hunt” in many different files for potentially hundreds of instances. ### Short-hand placeholders To reduce the amount of text you have to insert, Clause9 allows you to omit `?PLACEHOLDER :=` The example above can thus be shortened to: {% code overflow="wrap" %} ``` ... and @MR-MRS(#employee^gender, #employee^last-name) shall be obliged to do X, as supervised by @MR-MRS(#manager^gender, #manager^last-name) and assisted by @MR-MRS(#consultant^gender, #consultant^last-name) MR-MRS = {?A = "female": Mrs. | else: Mr.} ?B ``` {% endcode %} When no explicitly named placeholders are being used, Clause9 will assume that your placeholders are being named `?A`, `?B`, `?C`, … corresponding to the first, second, third, … parameter in the invocation of the snippet. {% hint style="info" %} When this short-hand method is being used, snippets look like invocations of special functions (such as `@count` and the many others). And that is exactly the idea — short pieces of “code” that allow you to avoid repetition. (Software developers call them “functions” or “methods”.) {% endhint %} # Parameters {% hint style="info" %} Parameters are an advanced subject that is only relevant to users who frequently have to draft complex clauses & documents. {% endhint %} Parameters are a tool that can be used in Clause9 grammar to make the use of [snippets](/clauses/snippets) even more flexible. They function as a kind of placeholder. Whereas snippets already enable you to replace a piece of text that is used multiple times across a clause or across several clauses/documents, combining snippets with parameters further upgrades the re-usability of a snippet by enabling you to replace the placeholder(s) in a snippet with different input each time you use the snippet. ## How to use parameters ### Insert the parameter as a placeholder in a snippet Parameters are written starting with a question mark, followed by a name of your choice in all caps. For example: `?NAME` or `?TYPE`. Written as such, the parameter should be used in the (internal or external) snippet as a placeholder for input that can be chosen elsewhere (i.e. where the snippet itself is being referenced). ### Give the parameter a value in the snippet reference Without a value, the parameter in the snippet itself will give an error message (the name of the parameter surrounded with a purple background). So to be of any use, it should be assigned a value. That is done in the snippet reference. The grammar for this is as follows: insert the snippet reference, followed by left parenthesis `(`. Insert the name of the (first) parameter. To assign it a value, insert `:=` followed by the relevant value. Multiple parameters can be assigned a value in one snippet reference by separating them with a comma. Close the reference off with right parenthesis `)`. The result looks like this: * for an **internal snippet**: `@SNIPPET-REFERENCE(?PARAMETER1 := value1, ?PARAMETER2 := value2)` * for an **external snippet**: `@#snippet-reference(?PARAMETER1 := value1, ?PARAMETER2 := value2)` (The only difference between these references is the way internal and external snippets themselves are referenced) ### Types of values The parameter can get nearly any value that results in a piece of text. The most important limitations are that a parameter value itself cannot be (i) plain text or (ii) a condition (however, note that use of the `@if` [special function](/special-functions/introduction) is allowed). Examples of values: * a concept reference * a datafield * a special function ## Example An example of a very simple notice clause will illustrate this:

Example of the use of parameters with an internal snippet.

# Conjugations One of the most powerful features of Clause9 is its grammatical knowledge, which allows you to automatically conjugate articles, verbs, adjectives and nouns to accommodate changes in conceptlabels. This page explains how to use these conjugations within the Clause9 grammar. {% embed url="" %} ## Basics **The basic idea is that you wrap both the #concept and the word that potentially needs adjustment in \. When the concept-label of the concept changes, the adjustments will then be automatically made (if no ambiguity exists).** For example: * `<#Buyer> a deal` will be printed as *“The Buye**r** negotiate**s** a deal”* in singular, and as *“The Buyer**s** negotiat**e** a deal”* in plural * `<#Buyer> assets` will be printed as *“The Buyer sells her assets”* in singular female, and “The Buyers sell their assets” in plural. There is no need to wrap a verb/article/adjective/… in angular brackets when you can determine in advance that it will never change, either because of grammatical reasons of because of contractual/legal reasons. For example: * In English, a verb in the infinitive or the present continuous tense will not change when the subject (noun) it is associated with, would change. For example, *“He is singing”* and *“They are singing”* both use exactly the same present continuous *“singing”*. Similarly, an auxiliary such as “will” — unlike has/have — does not need to change when its subject changes from singular to plural, so does not need to ever be wrapped in angular brackets.
* In many contracts, it will not make sense to anticipate that a certain concept will ever be put in singular or plural (or male or female). For example, if a company always delivers at least 100 kilogram of apples, there is no need to anticipate the singular version of “apple” in the delivery-clause. {% hint style="info" %} It is probably useful to understand what Clause9 is doing behind the scenes. When the time has arrived to print the final version of a conjugation, Clause9 will first check the currently chosen concept-label for the associated concept and note its number and (for languages that depend on this) its gender — e.g., singular noun, male. Clause9 will then check which grammatical function and conjugation you had written down between angular brackets — e.g., verb, present tense. It will then lookup all the conjugations for that word (lemma) in its dictionary, and choose that conjugation that corresponds to the concept-label’s setttings, *in casu* the singular, male version of the present tense. {% endhint %} ## Cases For language such as German and Lithuanian that support *cases* — nominative, genitive, dative, accusative, instrumental, locative — you can add the case after the concept. For example `<#Buyer: g>` or `<#Buyer: genitive>` would indicate that the concept’s noun should be conjugated in the genitive case. Similarly, you can also write `` to associate a certain adjective with the concept `#buyer`, but also put the adjective in the genitive form. Third example: `` would put a certain pronoun in the accusative plural, taking the gender from the `#buyer` concept. If you want to spell out the cases completely, please consult the following table: | Arabic | nominative – accusative – genitive | | ---------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Bulgarian | nominative – dative – accusative | | Czech | nominativ – genitiv – dativ – akuzativ – lokal – instrumental | | Danish | nominativ – genitiv | | German | nominativ – akkusativ – dativ – genitiv | | Greek | nominative – genitive – accusative | | Estonian | nominatiiv – genitiiv – partitiiv – illatiiv – inessiiv – elatiiv – allatiiv – adessiiv – ablatiiv – translatiiv- terminatiiv – essiiv – abessiiv – komitatiiv | | Finnish | nominatiivi – genetiivi – akkusatiivi – partitiivi – inessiivi – elatiivi – illatiivi – adessiivi – ablatiivi – allatiivi – essiivi – translatiivi – instruktiivi – abessiivi – komitatiivi | | Croatian | nominativ – genitiv – dativ – akuzativ – lokativ – instrumental | | Hungarian | nominative – accusative – dative – instrumental – causal – translative – terminative – essive – inessive – superessive – adessive – illative – sublative – allative – elative – delative – ablative | | Lithuanian | nominative – genitive – dative – accusative – instrumental – locative | | Latvian | nominativs – genitivs – dativs – akuzativs – lokativs – instrumentalis | | Norwegian | nominativ – genitiv | | Polish | mianownik – biernik – wolacz – miejscownik – celownik – dopelniacz – narzednik | | Romanian | nominativ – genitiv – acuzativ – dativ | | Russian | nominative – genitive – dative – accusative – instrumental – prepositional | | Slovak | nominativ – genitiv – dativ – akuzativ – lokalny – instrumental | | Slovenian | nominativ – genitiv – dativ – akuzativ – lokalni – instrumental | | Swedish | nominativ – genitiv | | Turkish | nominative – accusative – dative – locative – ablative – genitive – instrumental | {% hint style="info" %} For most languages, it is not necessary to fully spell out the name of the case: usually the first letter is enough, because the cases usually happen to have different starting letters. However, there are some languages where you need type in more letters — e.g. in Finnish you would have to type at least three letters, in light of the presence of the *adessiivi, ablatiivi, allatiivi* and *abessiivi* cases. {% endhint %} Instead of using the angular brackets to enforce a certain case, you can also use the `@case` special function. For example, `@case(#Buyer, "g")` or `@case(#Buyer, "gen")` will roughly have the same effect as `<#Buyer: g>` or `<#Buyer: genitive>`. However: * Unlike the `<...>`, the `@case` special function can be combined with other special functions, while still ending up as a defined term that can serve as the input for other special functions. For example, you can write either `@plural(@case(#Buyer, "g"))` or `@case(@plural(#Buyer), "g"))` to ensure that a certain concept-label is forced into the genitive plural. You can then “feed” that construction into yet other special functions — e.g. `@uppercase`(`@case(@plural(#Buyer), "g")))` would cause the concept-label to be shown in genitive, plural, uppercase. While it is possible to write `<#Buyer: g 2>` to force the buyer’s concept label into the genitive plural, it is not possible to feed that structure into other special functions, such as `@uppercase` ### Looking up the grammatical case Native speakers often do not know the grammatical case of words in their mother tongue. To help you finding the grammatical case of a certain word, Clause9 offers an artificial intelligence (AI) based grammatical function estimator. In languages with cases, you can click on the *Grammatical estimation* button, and then position your cursor on any word. Below the input box, you will then see the estimated grammatical case (and gender, number, etc.) of the word. {% hint style="info" %} Please take into account that this estimation is based on artificial intelligence, which has “learned” grammatical features by studying hundreds of thousands of sentences in each language. Even so, it will regularly make mistakes in its assessment. Also, the quality of the estimation will differ per language. {% endhint %}
## Forcing singular or plural You can force the use of singular or plural by inserting the number 1 (for singular) or 2 or 3 (for plural) after the colon. For example, `<#buyer: 2>` would force the buyer to be put in plural (similar to what `@plural(#buyer)` would achieve), while `<#buyer: gen 2>` would force the buyer to be put in both plural and the genitive case. You can also apply this to verbs/adjectives/pronouns — for example, `<#buyer: 2> ` would force both the concept and the verb (to have) to be put in plural. ## Associating words Real-life clauses are usually more complex than the two simple examples above. A first obstacle is that multiple concepts may be present in the same clause, which cause ambiguity: does the verb *causes* have to conjugate with buyer or seller in the example `If <#buyer> <#seller> to ...` ? Clause9 offers two different solutions to group words together: * You can use multiple angular brackets to associate a concept with other words — e.g. `If <<#buyer>> <> <#seller> to ...`. You can theoretically use any number of angular brackets, but in practice you probably want to limit this to three levels at most. * You can explicitly type in the concept after each associated word — e.g. `If <#buyer> <#seller> to ...` {% hint style="success" %} It is possible but not necessary to type in the hashtag. So both `` and `` are OK in the second example above. {% endhint %} ## Conjugating word types besides verbs Conjugating a verb is the most typical scenario. However, depending on the language, conjugating other types of words can also be useful: * **Articles** — while Clause9 allows you to configure, at the level of the concept-label, which article to use (a / the / this / no article), there are situations when the article and the concept are separated from each other — e.g. ` considerable <#defect> shall be fixed` will become *“**these** considerable defect**s** shall be fixed”* in plural.
* **Adjectives** (currently only supported in French) — e.g. ` <#-objet>` will be printed as *“cette grande Table”* for concept-label “Table”.
* **Pronouns** — e.g. `<#Employee> shall convert assets`
* **Nouns** — e.g. `#Supplier shall deliver the goods to <#employee>. shall then subject the goods to a quality-inspection.` will print as: * singular employee: *“Supplier shall deliver the goods to the Employe**e**. **This** perso**n** shall then subject the goods to a quality-inspection.”* * plural employees: *“Supplier shall deliver the goods to the Employee**s**. **These** person**s** shall then subject the goods to a quality-inspection.”* ## Grouping words together If multiple words that require conjugation are next to each other, then you can group them together. For example, instead of writing the following in German: {% code overflow="wrap" %} ``` ... wenn dies wegen geschieht, dann ... ``` {% endcode %} you can also write the following, shorter version: {% code overflow="wrap" %} ``` ... wenn dies wegen geschieht, dann ... ``` {% endcode %} Specifically for German, where certain prepositions always invoke a certain case in certain constructions, you can also include the special proposition within the group, and leave out the trailing case marker (“g” in the example above): {% code overflow="wrap" %} ``` ... wenn dies geschieht, dann ... ``` {% endcode %} In both examples, the result will be conjugated with the genitive case: … *wenn dies wegen des zweiten Käufers geschieht, dan …* ## Avoiding ambiguity The grammatical function of a word is often ambiguous. For example, in English, the word “table” can be both a noun and a transitive verb (*“to place on the agenda”*). `<#Employee> shall sell car` Unfortunately, software cannot determine a word’s grammatical function with 100% certainty. As even the most advanced artificial intelligence makes mistakes in this area — particularly in languages other than English — you will need to help Clause9 to determine the word function. {% hint style="success" %} Tip: often you can avoid ambiguity by putting a non-ambiguous conjugation of the word between the angular brackets. For example, stating `<#Employee> shall sell car` is ambiguous, because the word “her” can be both an indirect object (female equivalent of “him”) and a possessive pronoun (female equivalent of “his”). It is easier to use the non-ambiguous male versions: `<#Employee> shall sell car` and `<#Buyer> shall give the keys of the house`. Similarly verbs in languages other than French, it can be easier to simply use the opposite number (singular instead of plural) or different gender to avoid the ambiguities, even when grammatically speaking this does not make sense in the editor. For example, instead of writing `<#Employé> ` (which is ambiguous because “demeure” can be both a noun and a verb), you can simply write the plural version of the verb `<#Employé> ` , which is not ambiguous, even though it may look weird that the singular *employé* is combined with the plural verb *demeurent*. {% endhint %} When a word’s function is ambiguous according to Clause9 's internal dictionary, Clause9 will highlight *problems* in red:
… following which you can resolve inspect the problem, by positioning your cursor on the word in red:
## Custom conjugations Clause9 uses a dictionary with hundreds of thousands of lemmas for each language. However, some words will simply not be present in the dictionary. For those exceptional situations, you can however, add custom conjugations to a clause. Those custom conjugations can be added in two ways: either with a **mini-dictionary**, or **inline**. ### Mini-dictionary custom conjugations *(currently only available for Danish, Dutch, English, French, German, Italian, Lithuanian, Norwegian, Polish, Portuguese, Spanish and Swedish)* You will automatically be invited to add a word to the custom dictionary of a clause when you wrap an unknown word in angular brackets. For example:
After you choose the right grammatical function (in casu *verb*), Clause9 will then switch to the *conjugations* pane and allow you to enter the various conjugations for the relevant verb.
{% hint style="info" %} Depending on the grammatical function and the language considered, you may see many conjugations that can be completed. Do not feel obliged to exhaustively complete everything — e.g., for a verb, probably one tense in singular & plural (perhaps also in male & female in some languages) will be enough for a typical contractual clause. {% endhint %} ## Inline custom conjugations Instead of the mini-dictionary approach, you can also add custom conjugations “inline” (i.e., in the clause itself), by separating the conjugated forms by pipes. Several inline conjugations are available: * `` * `` * `` * `` Some examples: * `<#Employee> ` will be printed as *“The Employee agrees”* in singular, or as *“The Employees agree”* in plural. * `<#Employee> ` will be printed as *“The Employee is a man”* in singular male, as *“The Employees are men”* in plural male, as *“The Employee is a woman”* in singular female, and as *“The Employees are women”* in plural female. * `<#Employee> is ` will be printed as *“The Employee is a man”* in male, and as *“The Employee is a woman”* in female. ## Possessive form For some languages (such as English and Dutch) which adapt a defined term itself to indicate a possessive form, Clause9 can automatically output the correct possessive form based on the relevant singular/plural concept label. This is described on [the page on concept labels](/concepts/concept-labels#possessive-form). ## Frequently Asked Questions
Why do I see a purple error message? If you see a purple error message instead of your concept-label or verb/adjective/pronoun, then the software could not determine the conjugation. Usually, the software will provide you a hint on what went wrong. You can see this hint by **hovering your mouse over the purple error message**. If this does not help, then check the following steps: * For **concept-labels**: * Check whether you inserted the required grammatical word into the concept-label. For example, if you requested the word to be shown in plural (e.g., through `@plural`), then you must ensure that the plural version of that concept label effectively exists. * For languages with grammatical cases, you must ensure that a concept-label exists for that grammatical case. * Be aware that concept-labels cannot only be defined at the level of the concept (i.e., stored within the concept’s file), but can also be adhoc “**overruled**” (e.g., when you chose another concept-label in the popup-window of the Terms menu of Assemble Document). Even when you properly stored all required grammatical words for the concept-label in the concept’s file, you may not have done so when overrruling that concept-label from within the Terms menu. \ \ If such is the case, then you can either complete the adhoc-defined conceptlabel through the popup-window of the Terms menu. Alternatively, you can remove that adhoc-defined conceptlabel by clicking on the red “Revert to default” button in the popup-window. * For **conjugated** **verbs/adjectives/pronouns**: * Check whether you properly associated the conjugated word with a concept. For example, in simple clauses with only one concept, it can be sufficient to simply put \ around a verb or adjective. However, when multiple concepts exist, as well as in some edge-cases, the software may not be able to reliably figure out which concept to associate with. In such case, you should explicitly refer to the concept within the angular brackets, e.g. ``. * It may be the case that the word (or the required grammatical combination — e.g., third person plural in nominative case) was not found in the software’s internal dictionary. In such case, you can resolve the error by adding the relevant entry to the [mini-dictionary](#mini-dictionary).
Do I need to create two different versions of a Concept for the singular and plural? In many contracts, the same term happens to be used in both the singular and plural form. The typical example is term “Party”, which is also used as “Parties”. The question arises whether, in Clause9, you should create two different Concepts in such situation. For grammatical purposes, it is not necessary to create two different Concepts for the same term. After all, assuming you have specified both the singular and the plural form in the concept label of the Concept, the special functions `@singular` and `@plural` allow you to easily different between the two grammatical forms. From a legal perspective, it may be the case that you want to either assign a different meaning to the singular and plural form, or at least explicitly clarify how the singular and plural form should be interpreted. (E.g., in contracts with more than two parties, it may be ambiguous whether “the Parties” refers to “at least two parties (but not necessarily all of them)” or instead to “all of the parties”.) In such case, many legal experts will insert two different entries in the definition list, one for the singular form and one for the plural form. If you happen to find yourself in this situation, you will indeed have to create two different Concepts. The reason is that if you create only one Concept, and force its singular or plural form through `@singular` and `@plural`, then Clause9 will only insert one entry into the definition list. You will probably want to ensure that the default concept label for the singular Concept is the singular form of the term, while the default concept label for the plural Concept is the plural form of the term
# Mixing data types While drafting clauses in Clause9 is certainly not “programming” in the traditional sense, Clause9 borrows some best-practices from traditional programming languages. Legal experts who have never done any traditional programming are often confused by these practices. One such issue is the concept of *data types* — aka the issue of *not mixing apples and oranges*. This page deliberately takes a deep-dive into dealing with these types, to fully explain how they work in Clause9. ## Natural language versus conditions & calculations \ A first important idea to grasp is the distinction between *natural language mode* and *conditions/calculations mode*. The standard mode in Clause9 is the natural language mode. This is the mode you will implicitly arrive in when starting to type something in a clause. It will consist of “human” language stuff, such as words in English/French/Dutch, punctuation and numbering, etc. For example, the following clause entirely consists of the natural language mode elements:
A clause that consists entirely of natural language mode elements will be completely static, i.e. aside from the numbering and formatting of the clause, this clause will not change appearance. To insert dynamic elements, you insert conditions and calculations, for example:
As soon as you type in an opening accolade **`{`** you will leave the natural language mode, and enter either * the **condition mode**, for which the result’s type is always true or false); or * the **calculation mode** (for which the result’s type depends on the kind of calculation being made). In the example above, `#contract^value < 500 EUR` and `#contract^value < 2000 EUR` are written in the condition mode, while `apples^amount * #apples^unit-price` is written in the calculation mode. After the closing accolade **`}`**you will in any case leave these modes, and return to the natural language mode. However, the switch between the modes is more complex than just looking at the opening and closing accolade. For example, in paragraph 1. above, the parts between the colon (`:`) and the vertical bar (`|`) are once again in the natural language mode, i.e. the words *low* and *medium* and *high*. ## Calculation mode As the name implies, calculation mode expects to perform calculations. The input to these calculations consists of a mix of **countable elements** and optional **operators** — e.g. `5 + 24` or `5 * 4.5 EUR`, but also `12 months * 4` or `2020_11_23 + 3 days`, because you can perform interesting calculations with durations and dates. Instead of using directly countable elements, you can also work with elements that ultimately boil down to numbers. For example, in `apples^amount * #apples^unit-price`, the datafields “`amount`” and “`unit-price`” can be assumed to contain countable things. When, for example, the number 5 would be assigned to `apples^amount` and the `#apples^unit-price` would be assigned the value 0.4 EUR, Clause9 will happily perform the calculation for you and return the result (2 EUR). Note that natural text cannot, as such, be used in calculation mode. After all, text is — as such such — not countable. It does not make sense to, for example, perform a calculation to divide the words *“the Buyer buys an apple”* by the words *“the Seller sells a pear”*. ## Condition mode Writing in the condition mode will be writing in calculation mode, with one exception. Condition mode is meant to ultimately result in *true* or *false*, and will therefore contain a **left side** **with a calculation**, a **comparison operator** and a **right side** **with yet another calculation**. For example, in the condition `apples^amount * #apples^unit-price < 2000 EUR`, you will see a left side (containing a calculation on apples), a comparison-operator (smaller than <), and a right side (with a single currency-value). ### Data type In Clause9, as in most programming languages, you can only calculate with elements of the same data type, and you can only compare elements of the same data type. For example, it does not make sense to add 25 EUR to a date, or to compare the text “alpha” to the duration of 5 months. Clause9 offers the following basic data types: | Data type | Examples | | --------------------- | -------------------------------------- | | whole number | `0`; `5`; `21456` | | floating point number | `4.56`; `2457.8975` | | currency number | `0 EUR`; `56.34 EUR` | | text | `"alpha"`; `"Main Street 56 Brussels"` | | date | `5 January 2020`; `8 July 2022` | | duration | `3 years`; `4 months`; `2 days` | | true/false | `true` | In addition, the following special data types are also offered. | Data type | Example | | ------------------------------------------------- | ------------------------------------------------------------------------------- | | list of elements (any of the other types allowed) | `5`, `6 EUR`, `3 January 2020` | | clause text |

1. Alpha
\* Beta
\*\* Gamma

| | clause part | `@ALPHA` | | defined term | `#contract` | | datafield reference | `#contract^value` | | nothing / undefined | | The three different modes result in three different data types:
| Mode | Result | | --------------------- | --------------------------------------------------------------------------------------- | | natural language mode | always results in *clause text* | | calculation mode | result type will depend on the elements used — e.g. `3 + 3` results in a *whole number* | | condition mode | always results in *true/false* | ## Supported currencies Clause9 currently supports the following currencies: | Currency | Symbol used in Clause9 | | -------------------- | ---------------------- | | euros | EUR | | British pound | GBP | | United States dollar | USD | | Japanese Yen | JPY | | Australian dollar | AUD | | Canadian dollar | CAD | | Swiss franc | CHF | | yuan | CNY | | Kenyan shilling | KSH | | Hong Kong dollar | HKD | | New Zealand dollar | NZD | | Swedish krona | SEK | | South Korean won | KRW | | Singapore dollar | SGD | | Norwegian krone | NOK | | Mexican peso | MXN | | Indian rupee | INR | | Russian ruble | RUB | | South African rand | ZAR | | Turkish lira | TRY | | Brazilian real | BRL | | New Taiwan dollar | TWD | | Danish krone | DKK | | Polish złoty | PLN | | Thai baht | THB | | Indonesian rupiah | IDR | | Hungarian forint | HUF | | Czech koruna | CZK | | Israeli shekel | ILS | | Chilean peso | CLP | | Phillipine peso | PHP | | UAE dirham | AED | | Colombian peso | COP | | Saudi riyal | SAR | | Malaysian ringgit | MYR | | Romanian leu | RON | ## Conversions between data types While it is not possible to perform calculations or comparisons with elements of different data types, it is possible to convert an element to another data type. This conversion can either be done **explicitly** or **implicitly**. ### Explicit conversions Explicit conversions can be achieved using [special functions](/special-functions/introduction). For example, the special function `@extract-number` will take a *currency number* (e.g., `5.5 EUR`) and return the *floating point number* (`5.5`). Similarly, the sole purpose of the special function `@str` is to convert the argument passed to it into *text* — e.g. `@str(3 months)` will, depending on the styling settings, result in the *text* `3 months` when the active language is English. {% hint style="info" %} At first glance, this may look like nothing changed; under the hood, however, the type of this element changed from a *duration* to a *text*, meaning that the operations that can be applied to a *duration* element (e.g., addition or subtraction) will suddenly no longer work, while the operations that can be applied to a *text* element (e.g., capitalization) will suddenly become possible.\ \ If the active language is not English, the conversion will be much more visible. For example, `@str(3 months)` may also be converted to *“trois (3) mois”* in French, with a styling setting where numbers are always converted to both letters and numbers. {% endhint %} Most special functions will perform something more than solely converting an argument from one data type to another data type. Examples: * `@round` and `@floor` will convert the *floating point number* passed to them, and then either round that number or truncate the decimal part, returning a *whole number* * `@comma-split` will take a *text* element and return a *list* element that contains individual text elements (e.g. `@comma-split("alpha, beta, gamma")` will return a *list* with *text* elements `"alpha"`, `"beta"` and `"gamma"`. ### Implicit conversions of basic data types It would be cumbersome to always have to explicitly convert data types — e.g., imagine that in order to take 5.5 times the duration of a contract, you would have to write `5.5 * @float(@months-in(#contract^duration))` {% hint style="info" %} The underlying reasoning is as follows: you are performing a multiplication of a *floating point number* and a *duration*, which is not possible. There exists a special function `@months-in` that takes a duration and returns a *whole number* that corresponds to the amount of months in that duration. However, you would then have to perform yet another conversion from this *whole number* to the *floating point number*. You would therefore have to use the hypothetical `@float` function. {% endhint %} To avoid these situations, Clause9 will implicitly perform conversions for you when no ambiguity is involved: | Data type 1 | Data type 2 | Resulting data type | Example | | ----------------- | ----------------- | ------------------- | ------------------------------------------------------------------------------- | | whole nr | floating point nr | floating point nr | `5 + 5.5` results in `10.5` | | whole nr | currency nr | currency nr | `200 + 300 EUR` results in `500 EUR` | | floating point nr | currency nr | currency nr | `229.5 + 300 EUR` results in `529.5 EUR` | | date (\*) | duration | date | `2018_7_12 + 1 month` results in `2018_8_12` | | list (\*\*) | (any data type) | list | `@list("alpha", "beta") + "gamma"` results in `@list("alpha", "beta", "gamma")` | * (\*) When mixing a date with a duration, note that the order and operation matters. The conversion will only be applied with `date +/- duration`. If you change the ordering (e.g., duration first) or the operation (e.g. multiplication), the result will be an error.
* (\*\*) When mixing a list with, the order and operation matters: the conversion will only be applied with `list +/- element`, not with `element +/- list`. * When using the `-` operator, the element(s) at the right side are removed from the list at the left side. For example, `@list("alpha", "beta") - "alpha"` and `@list("alpha", "beta") - @list("alpha")` both result in `@list("beta")`. * When using the `+` operator, the result depends on the right-side: * If both the left & right side are lists, then the result will be a *concatenation* of the two lists, with all the elements of the right list appended to the left list, irrespective of whether they were already present in the left list. For example, `@list("alpha", "beta", "gamma") + @list("alpha", "delta")` will result in `@list("alpha", "beta", "gamma", "alpha", "delta")`. (If you want a *union* of the list, where elements-already-present are not added again, use the `@union` special function instead of +). * If the right side is not a list, then it will be added as a new element of the left list, irrespective of whether the right side element was already present in the list. For example, `@list("alpha", "beta") + "alpha"` will result in `@list("alpha", "beta", "alpha")`. (If you want a *union* of the list and the single element, where the right-side element is not added again to the left list, use the `@union` special function instead of +). ### Implicit conversions of undefined When using datafields, values will often not be present, because they have not (yet) been filled in by the end-user. Within a calculation/condition, to avoid errors, Clause9 will try to convert this undefined value to a sensible default value: | **Datatype** | **Converted into** | **Example** | | ------------ | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | | number | 0 | `55 * undefined` results in *0* | | currency | 0 (same valuta) |

5 EUR + undefined results in 5 EUR
5 EUR \* undefined results in 0 EUR

| | duration | duration with length 0 | `5 days + undefined` results in *5 days* | | text | empty text | *empty text is simply ignored in the output* | | list | empty list | `@list("alpha") + undefined` results in `@list("alpha")` | {% hint style="danger" %} Note that the date field is missing from the table above: an undefined will never be implicitly converted to a date field. (After all, there exists no date that would make sense here: what could possibly be considered “date zero”?) {% endhint %} {% hint style="info" %} Tip: when you do not like these implicit conversions of unavailable values inside a calculation, you may want to use [an exclamation point after the hash](/clauses/special-codes#exclamation-marks-before-datafields).\ \ For example, while you may be happy with `{#apples^amount * 0.2 EUR}` resulting in 0 EUR when the amount of apples has not yet been completed by the end-user, it may equally be the case that you absolutely need the user to fill in this amount. If so, then use `{#apples^!amount * 0.2 EUR}` instead — this will result in a box that invites the user to fill in this value, signaling that the calculation simply cannot be completed without a value assigned to the amount of apples. {% endhint %} ### Implicit conversions to true/false in a condition In condition mode, the following implicit conversions are carried out to convert a data type to true/false: | Data type | Converts to *true* when | Converts to *fals*e when | | ----------------------------------------- | ----------------------- | ---------------------------------- | | Text | Non-empty text value | Equal to the empty-text value (“”) | | (Whole/floating/currency) number | Not equal to 0 | Equal to 0 | | Duration | Amount higher than 0 | Amount equal to 0 | | List | Not empty | Empty (no elements) | | Date | Assigned some value | Never | | Undefined (e.g., datafield without value) | Never | Always | Note that in an *if-then-else* condition, you can omit the operator and right-hand side of the comparison for the sake of brevity; Clause9 will then automatically insert `= true`. For example: * Instead of writing `{#contract^is-dutch-law = true: ... }` you can also write `{#contract^is-dutch-law: ... }`. If the datafield `is-dutch-law` is a *true/false* datafield, then no implicit conversions will occur. * Instead of writing `{#contract^value > 0: ... }` you can also write `{#contract^value = true: ... }` or the shorter version`{#contract^value: ... }`. In both of these cases, the `contract-value` *whole number* datafield will be converted into a true/false, meaning it will result in *true* if a non-zero value is assigned to this datafield; it will instead result in *false* when no value is assigned at all, or when the value that is assigned to this datafield, is equal to zero. ### Implicit duration conversions When combining *duration* elements of different units in a calculation, conversions may be necessary — e.g., when you add `2 days` to `3 months`. You should be aware that such conversions will in many cases result in rounding errors and unexpected results, because a duration does not contain any context about the month or year it relates to. Clause9 will convert durations with different units into the lowest time unit, e.g. *year + months* will be converted to months, *year + days* will be converted into days, and *months + weeks* will be converted into weeks. Clause9 tries to use sensible averages during this conversion, but unexpected results are bound to happen due to the lack of context. **The bottom line is that you should try to avoid these implicit conversions as much as possible.** {% hint style="info" %} For example, Clause9 happens to convert `27 months + 1 day` to 822 days, because it first converts 27 months to two years (= 730 days) and 3 months (= 3 times average of 30.417 days, so 91 days), and then adds yet another day. An equally sensible result would, however, be 811 days (= 27 \* 30 days + 1 day).\ \ Similarly, Clause9 happens to convert a month into 4.345 weeks, so that `3 months + 1 week` gets converted to 14 weeks. Other software or people would perhaps answer 13 weeks. {% endhint %} ### Implicit conversions to clause text Clause9 allows you insert a datafield directly into natural text. For example:
While perhaps not immediately obvious, this is also a situation where apples (clause text) are combined with oranges (number datafield). To avoid that you would have to insert all kinds of ugly codes to allow this, Clause9 will implicitly convert this datafield into clause text for you. In most situations, this conversion will be very straightforward. However, do note the following. * A (whole/floating point/currency) *number* and a *date* value be converted into text in accordance with the locale styling rules (e.g., for the decimals style, currency symbol placement, short/long date format, etc.). * A *true/false* value will get translated — e.g., `Alpha {true}.` will be converted into `Alpha true` in English and `Alpha vrai` in French. * A *list* value will have its elements printed consequentially with spaces in between — e.g. `@list("alpha", "beta", "gamma")` will be converted into `alpha beta gamma`. If you want to have comma’s plus and/or etc. in such list, or perhaps convert it into a bullet-list, then you need to use one of the special functions — e.g., `@enumerate-andor(@list("alpha", "beta", "gamma"))`. ### Avoided implicit conversions Some conversions are deliberately not performed, because they would be ambiguous: * Adding a (whole/floating/currency) number to a duration or date. For example, `3 months + 3` results in an error because it will be difficult for the software to figure out whether you want the result to be a duration (6 months) or a whole number instead (6). * Adding a number to a date. For example, `2020_04_07 + 3` results in an error, because it is not clear whether you would like to add 3 years, 3 months, 3 weeks or 3 days instead. Other conversions are deliberately not performed because they make no sense: * Mixing *text* and *whole/floating/currency numbers*. It will usually be obvious that this does not make sense — e.g. `"alpha" + 6` — but this may not always be intuitive to those new to Clause9.\ \ For example, if you create a *text* datafield `#contract^value`, then Clause9 will treat the contents of this datafield as text, and issue an error when you try to do a calculation such as `#contract^value * 2`. This error will make perfect sense when the end-user would type in “real” text (such as the word *“Paris”*), because you can obviously not multiply Paris by two. However, when an end-user would type in a number (e.g., 3500), then it will not be so obvious why the software is complaining. ### Disallowed operations While not a data type conversion issue, you should also note that some operations are not allowed between elements of the same data type: * You cannot mix different currencies — e.g., adding `{200 EUR + 300 USD}` results in an error. * You cannot add dates to each other — e.g. `{2020_04_03 + 2020_05_3}` results in an invalid operation error. ## Dealing with the data type of if/then/else An if/then/else construction will normally result in clause text. For example, {% code overflow="wrap" %} ``` 1. Upon drafting @CONTRACT, the parties agreed to have @CONTRACT screened by the authorities. If @CONTRACT would turn out to be ... CONTRACT = {#contract^with-annexes: this Employment And Restructuring Contract (ERC) including its annexes | else: this ERC} ``` {% endcode %} The contents of the [internal snippet](/clauses/snippets) CONTRACT will be clause text, because its sole element is an if/then/else construction between curly braces. Such clause text can be inserted into the main body of the clause without any conversion being necessary. However, it is also possible to use the if/then/else construction to return other data values. You can do this by wrapping the content of the if/then/else after the colon (:) between curly braces. For example: {% code overflow="wrap" %} ``` 1. Buyer will pay an amount equal to {@INTEREST * 1.5} before 1st January. If this payment is not successfully performed, it will be automatically increased to {@INTEREST * 2}. INTEREST = {#contract^jurisdiction = "dutch": {0.05 * #contract^value} | else: {0.08 * #contract^value} } ``` {% endcode %} It is interesting to analyse why you will get a *“value is not a number”* error when you omit the two pairs of curly braces in the if/then/else construction: {% code overflow="wrap" %} ``` 1. Buyer will pay an amount equal to {@INTEREST * 1.5} before 1st January. If this payment is not successfully performed, it will be automatically increased to {@INTEREST * 2}. INTEREST = {#contract^jurisdiction = "dutch": 0.05 * #contract^value | else: 0.08 * #contract^value } ``` {% endcode %} The reason is that Clause9 will do the following: * When encountering the `{@INTEREST * 1.5}`, it will replace the @SNIPPET with the contents of the internal snippet, arriving at `{#contract^jurisdiction = "dutch": 0.05 * #contract^value | else: 0.08 * #contract^value } * 1.5` * It will then execute the if/then/else construction, and check whether the contract’s jurisdiction is equal to “dutch”. Assuming this is indeed the case, Clause9 will notice that the associated fragment it has to insert into the main part of the clause is `0.05 * #contract^value`. * Because this fragment is not wrapped in curly braces, Clause9 will treat the fragment as clause text. For example, if the contract’s value is currently set to 1000, and the current styling happens to be metric, it would convert the fragment into the text *“0.05 \* 1.000”* . Notice that: * because the fragment is treated as clause text, Clause9 will treat the 0.05 literally, i.e. not consider it to be a number. Accordingly, despite the fact that the styling settings are set to metric (so that a floating point number such as 0.05 would be printed with a comma as “0,05”), Clause9 will print it as “0.05” * the contract’s value (1000) is a *whole number* that is inserted into clause text, and will therefore get converted to clause text, respecting all the styling settings (such as the metric style’s dot between the 1 and the three zeroes) * Next, it will try to multiply the clause text *“0.05 \* 1.000”* by the number 1.5, which obviously does not make sense because you cannot multiply text by a number. It will therefore issue a warning *“value is not a number”*. `Pursuant to article 3§4 of the Civil Code, #Buyer shall ...` ## Examples Why is `shall pay 10.20 EUR` printed as “shall pay 10.20 EUR”, while my styling settings dictate metric style with a euro-symbol? Why do I see an error message with `Pursuant to article 3§4 of the Civil Code, #Buyer shall ...` ? I get an *“incompatible argument types”* error when using the following clause:\ \ `#Buyer shall pay interest equal to @days-between(#contract^start-date, @today)` The software does not accept the following clause (shows a yellow error):\ \ `#Buyer shall pay interest equal to @days-between({#contract^prolonged: #contract^prolongation-date | else: #contract^start-date}, @today)` # For-loops Using the `@for` and `@for-calc` functions, you can generate a list of items (snippets of text, numbers, dates, …) by *iterat*ing through another list of values. Programmers will be very familiar with this idea, as *for-loops* are essential ingredients of most programming languages. For legal professionals, this idea will sound much more abstract — we will therefore explain the idea through relevant examples. ## Basic structure When using `@for` and `@for-calc`, you have to specify three different parameters: a placeholder, a list of elements to iterate (“loop”) with, and an internal snippet that will be used in each iteration. For example, ``` @for(?X, @list("alpha", "beta", "gamma"), @SNIP) SNIP = this is element ?X ``` This code will loop through the bottom snippet three different times, each time replacing the placeholder `?X` with the next element of the list. Accordingly, the result will be a list of texts containing *“this is element alpha”*, *“this is element beta”* and *“this is element gamma”.* You can then use this resulting list in any way possible, for example convert it into bullets using `@bullets( ... )` or into an inline-enumeration using `@enumerate`. The difference between `@for` and `@for-calc` is that `@for` will always resulting in a list of text snippets (i.e., a word, a part of a sentence, or even entire paragraphs), while `@for-calc` will result in a list of values, whereby each value must be a whole/floating number, a currency value, a duration, undefined, or a list itself. If `@for-calc` cannot extract such value (e.g., because the intermediate result is a text snippet), then it will result in an error. In addition to the placeholder you specify yourself (`?X` in the example above), the software will also allow you to use the following *implicit* placeholders: * `?INDEX` will contain the current iteration number, starting from 1 and increased with each iteration. * `?MAX-INDEX` will contain the total number of iterations that will be performed. Note that this value will remain constant throughout all iterations. * `?PREVIOUS` will contain the result of the previous iteration * `?ACC` (for “accumulator”) will contain the list of results up to (but not yet including) the current iteration In the example below, three iterations are shown, whereby `?X` will be assigned the value 10, 11 and 12 respectively, while the `?INDEX` will be assigned the value 1, 2 and 3 respectively. Note that the `?PREVIOUS` value will not contain a value in the first iteration (for obvious reasons). In the second iteration, it will contain the bullet that resulted from the previous iteration; in the third iteration, it will contain the bullet of the first iteration, as well as the sub-bullet of the second iteration. The example in the screenshot below is contrived, but you will see in the real examples below how the `?PREVIOUS` value can be used.
## Looping through dates In a loan agreement, we want to create a list of bullets that contains an overview of all the monthly repayment dates, starting from a certain commencement. The parameters of the loan are saved into the datafields `loan^start-date`, `#loan^frequency` (a duration — e.g., one month or 2 weeks) and `#loan^instalments` (the number of repayments, e.g. 5). Using a for-loop, we could then write: {% code overflow="wrap" %} ``` @bullets(@for(?INSTALMENT-NR, @range(1, #loan^instalments), @BULLET)) BULLET = ~@ord(?INSTALMENT-NR) repayment~ on {#loan^start-date + (#loan^frequency * ?INSTALMENT-NR) } ``` {% endcode %} In human language, this roughly means the following: * create a list (range) of items, starting from 1, up to (but including) the number of instalments — e.g. from 1 to 5 * create a resulting list in memory, that will hold all the intermediate results * do the following 5 times: * set placeholder `?INSTALMENT-NR` to the current item (i.e., the first time set it to 1, the next time to 2, etc.) * take internal snippet `@BULLET`, and replace placeholder `?INSTALMENT-NR` with its current value * put the intermediate result into the resulting list * take the resulting list, and convert it into bullets. The results can be seen in the following screenshot, when using the [focus mode](/assemble-document/focus-mode). You are strongly recommended to use this focus mode, because it allows you to interactively experiment with the for-loops.
Particularly interesting in the focus mode is its ability to [isolate](/assemble-document/focus-mode#isolating) a particular snippet. For example, when you isolate snippet `@BULLET`, and then assign values to the `?INSTALMENT-NR` placeholder through the button, you can interactively “step through” each iteration. (Programmers sometimes call this *“debugging”*, i.e. a mode dedicated to removing potential “bugs” from their software code).
## Looping through indexed values Let’s assume that in a rental agreement you need to show the indexed rent amount over a certain period. For example, with a starting amount 1000 EUR and a yearly indexation of 5%, you may be tempted to write the following:
Unfortunately, this is not how most real-world indexation clauses work, as the indexation should take the then-applicable amount as the starting point each time. This can be solved using the `?PREVIOUS` placeholder. In the example below, we use `@for-calc` to calculate a list of all rental amounts, which is then shown in another `@for`-loop. (The reason being that a `@for` loop results in a piece of text, that cannot be used in further mathematical calculations):
The `AMOUNT` snippet essentially says *“if no previous value exists (i.e., we are at the first iteration), then simply use the base amount; however, if a previous value exists (which should be the case as from the second iteration), then use the previous value and apply the indexation to it”*. Note that we use curly braces around the result in the `AMOUNT` snippet in order to force the result to become a number. If you leave these curly braces, you immediately get errors, because the software would then treat the result of that snippet as a piece of text, while`@for-calc` can only work with a number / currency value / duration / list / undefined value. ## Debt payments table As another example, let’s assume that a contract wants to show a table that illustrates how an amount of 1000 EUR is paid back over five months. The calculation per period is deliberately kept very simple, but the idea is clear that you could also use the various types of mortgage payment calculations here. What we’re doing here, essentially, is to construct a table that consists of six different rows (a header row, and one row per repayment-period), merged together using `@merge-tables`. Each repayment period’s row then contains a cell with the calculated date, the amount (in the example always 200), and then a cell with the remaining value. The remaining value is extracted using `@get` from a list of repayment amounts that is generated by the `@AMOUNTS-LIST` snippet, which uses a simple `@for-calc` loop. Note that when the loan amount, number of periods, starting date, etc. are placed in datafields, this kind of table can even be interactively shown within a Q\&A, allowing end-users to experiment with these values.
# Clause versioning ## Why? Thanks to Clause9's centralised approach, any change in a library clause will immediately show up in all documents and binders that make use of that clause. Usually, this is exactly what you want, because it avoids that you would have to apply the same change in many different files, as is the case in Microsoft Word and other template-based editors. While you can easily create a copy of a library clause, modify that copy and then use that modified copy it in future contracts, it can be very useful to indicate that certain clauses are historically linked to each other. This is what clause versioning is all about in Clause9. A typical use case for clause versioning is when **legislation changes** — *e.g.,* a certain requirement becomes blacklisted, or a certain duration is extended from 6 months to 2 years. Another use case is when **internal policies change** — *e.g.,* the default payment term is shortened from 2 months to 1 month. ## Applying versioning Clauses are not versioned by default: you explicitly need to initiate the versioning. You do so by clicking on the versioning button (right side of the clause editor).
{% hint style="info" %} Your administrator may have disabled this button. By default, it is only visible for advanced user accounts. {% endhint %} You will then see the following popup, from which you choose the bottom option *Initiate Versioning*
Next, you need to specify a name for this version, which — presumably — will be the old version. A potential name is, for example, *“June 2020 version”*.
When you save this version, the *version name* will be shown in green in the file browser:
You can then create another version of the same file by, once again, clicking on the versioning button. In the popup that appears, choose *“create new version”*.
Clause9 will then create a new version of the file. This new version will, by default, receive the current date as its *version name*, but you can change it to any name that makes sense. Note that the newly created version is not yet set as the *active version*. In the file browser, the new version will therefore be shown with a grey label.
In order to set a certain version as the active version, click on the versioning button and choose *“set as the active version”*:
## How versioning is implemented From a technical point of view, each version of a clause is essentially just a clause. Anything you can do with a regular clause (insert in *Assemble Document*, move, delete, rename, etc.), you can also do to versioned clauses. The only special feature of a versioned clause is that it contains a version-link to its other versions, which is visible in the file browser by way of the green or grey version label. Also, by choosing *Show other versions*, you can open the other versions in *Browse files*. Another special behaviour is that the *Search pane* contains a checkbox *all versions* that allows you to specify whether all versions of a file should be shown (assuming they each meet the search criteria), or whether instead only the active version should be shown. ## What versioning is *not* Except for their grey label, old versions of a file are regular files that behave like any other files. In other words: * they can still be inserted into documents by users * they can still be modified (whereby their changes will immediately be reflected in all documents that make use of them) * they can be moved independently to other folders, irrespective of the location of the other versions Accordingly, **the mere act of labelling a clause as an old version, will not cause it to become immutable** — so changes are still possible if a user has the right to do so. If you really want to avoid that an old version gets changed, then change its access rights, e.g. by moving it to a write-protected folder. {% hint style="success" %} It is probably a good idea to move old versions to a separate folder, e.g. called “archived versions”. {% endhint %} # Abstract article references Clause9 allows you to easily create automatic [cross-references](/clauses/cross-references) to other parts of your document. However, there are a few situations when you want to refer in an abstract way to an “article” or “section” of your document. Examples: *The buyer shall buy the assets in the manner set forth in the articles above.* or *The articles of this contract shall be construed in accordance with …* You may be tempted to hard-code the word “articles” here. However, this may impede reusability, as some lawyers will want to use the word “section”, “paragraph”, or perhaps an abbreviation such as “art.”, or perhaps a word that always has a starting capital. Clause9 allows you to instead use a special expression, that will output in accordance with the styling settings found under “References”.
The special expression essentially consists of the word “article” (for singular) or “articles” (for plural), but actually depends on the language: | Language | Singular | Plural | | ---------- | -------------- | --------------- | | Bulgarian | \_`_клауза_` | \_`_клаузи_` | | Czech | `_bod_` | `_body_` | | Danish | `_klausul_` | `_klausuler_` | | Dutch | `_artikel_` | `_artikels_` | | English | `_article_` | `_articles_` | | Estonian | `_klausel_` | `_klauslid_` | | Finnish | `_lauseke_` | `_lausekkeet_` | | French | `_article_` | `_articles_` | | German | `_artikel_` | `_artikeln_` | | Hungarian | `_záradék_` | `_záradékok_` | | Italian | `_clausola_` | `_clausole_` | | Latvian | `_klauzula_` | `_klauzulas_` | | Lithuanian | `_straipsnis_` | `_straipsniai_` | | Norwegian | `_klausulen_` | `_klausulene_` | | Polish | `_klauzula_` | `_klauzule_` | | Portuguese | `_cláusula_` | `_cláusulas_` | | Romanian | `_clauza_` | `_clauzele_` | | Russian | `_пункт_` | `_пункты_` | | Slovak | `_doložka_` | `_doložky_` | | Slovenian | `_klavzula_` | `_klavzuli_` | | Spanish | `_cláusula_` | `_cláusulas_` | | Swedish | `_klausul_` | `_klausulerna_` | By default, the word will be outputted with a defined article (no pun intended), but this can be modulated in the same way as concepts. For example, for English, assuming the styling setting is set to “Section”: * **default:** `_article_` is outputted as “the section”, while `_articles_` is outputted as “the sections” * **omitting**: `_-article_` is outputted as “section”, while `_-articles_` is outputted as “sections” * **undefined**: `_?article_` is outputted as “a section”, while `_?articles°_` is outputted as “sections” * **this**: `_°article_` is outputted as “this section”, while `_°articles_` is outputted as “these sections” {% hint style="info" %} For the sake of consistency or clarity, you can also use `_+article_` or `_+articles_`, but it will have exactly the same output as the default `_article_` / `_articles_`. {% endhint %} ## Caveat The `_article_` expression can be useful in a few very specific circumstances. However, its use cases are actually fairly limited: * Please do not use it to hard-code references to other parts of your document — e.g. when you would be tempted to write `... as set forth in _-article_ 13.5` to refer to some article 13.5 in your document, you will almost certainly want to use [real cross-references](/clauses/cross-references) instead.
* Please do not use it to refer to articles/sections/clauses of external material, such as legislation, as the word that will be outputted will then change in accordance with a user’s styling preferences. For example, European Directives and Regulations are typically numbered as “articles”. If you need to refer to the part of the EU General Data Protection Regulation that lists all the definition, please do not say `... as defined in _-article 4_ of the GPDR ...`, as this could get outputted as “… as defined in Section 4 of the GDPR”, depending on a user’s styling preferences. This is one of the few areas where you really need to hard-code your reference, by simply stating `.... as defined in article 4 of the GDPR...` # Advanced multi-language features One of Clause9's strongest assets, is how it handles multiple languages. In this article, you can learn all about advanced features. ## The basics: printing a document in multiple languages When all the clauses of a document are available in multiple languages, you can easily export a document in multiple columns by checking one or more languages in the export settings of Assemble Document.
Within a Q\&A, the end-user can instead go button in the upper-right corner, and activate the same options from the popup-menu. Note that, unlike Assemble Document (for which the user interface is always in English), you can optionally translate the cards, questions and predefined options of a Q\&A, and allow the end-user to switch the relevant language on-the-fly.
## Fine-grained control over multiple languages in the Q\&A. The Q\&A options discussed above cannot be subjected to conditions. If you need more fine-grained control, you can insert two types of changes. A first change is the “**Change the save/export settings**“, which contains a subsection that allows you to specify which languages (if any) need to be exported in columns.
When at least one extra language is checked, you can also specify dynamically the orientation and the optional borders between columns:
By subjecting the surrounding change-set to conditions, you can determine in which circumstances certain languages must be (de)activated. More detailed information can be found [elsewhere](/qna/types-of-changes). A second type of change is the “**Change various Q\&A options**“, which allows you to dynamically change the language of the user interface.
## Language-related conditions in a Q\&A In a Q\&A, there are two types of conditions that allow you to only show certain cards/questions/answers when certain languages are visible.
## Language-related conditions in a clause When drafting a clause, you can use a series of [special functions](/special-functions/languages), such as `@english` and `@french` (or any other language supported by the server you are using), to enable/disable certain clauses or snippets of text. For example a condition such as `@english AND #contract^value > 1000 EUR` would only be shown when the contract is currently being printed in English, and the contract’s value is simultaneously higher than 1000 EUR. Note that when a contracting would be exported in multiple languages at the same time (e.g., English and French), this may cause the clause to be shown in the French column, but be hidden in the English column. ## Reusing the clause contents between languages It may happen that your clause does not contain any language-specific content, so that exactly the same contents should be shown in all available languages. You can of course copy-paste the same contents in each of the language boxes, but from a clause management perspective, this will cause extra work when you want to update that clause, as you will need to make the same changes to each of the languages. Instead of copy/pasting, you can insert `// Use English` into the other language boxes to copy the contents from the English box. (Similarly, you could type `// Use French` to copy from the French language box.)
You could even mix-and-match the language content to reuse. For example, on the server above (which supports English, Dutch, German and Lithuanian), you could provide English content, insert `// Use English` in Dutch and French (so that Dutch and French language versions of the document will show the English contents of this clause), but also provide a German version and insert `// Use German` in the Lithuanian version. {% hint style="info" %} Note that in the resulting MS Word-file, the paragraph(s) in question will then be in the target language. So if you use `// English`, the resulting paragraphs will be marked as English, even though the rest of the document will be marked with another language. {% endhint %} ## Always displaying a clause in a certain language Even when a clause would have multiple language versions, you can force a certain instance of the clause to always show up in another language. (This can also be useful when certain content is only available in one specific language — instead of hiding that content in the other languages, or having errors show up, you can select this option to always print that one specific language.) You can do so in Assemble Document by selected a clause and activating *Force clause to always show in:* in the Advanced pane at the right side.
{% hint style="info" %} Note that in the resulting MS Word-file, the paragraph(s) in question will then be in the target language. So if you use `// English`, the resulting paragraphs will be marked as English, even though the rest of the document will be marked with another language. {% endhint %} ## Avoiding translation in a multi-language export Even when you want to export a document with a column per language, there are certain clauses where you want to avoid this behaviour. The typical example is the signature block, which is usually not translated because it merely contains the names of the parties. To enable this behaviour for every instance of a clause, you can activate *Don’t translate in multi-language output* under the custom styling of a clause.
If, instead, you only want to enable this behaviour for one specific instance of a clause, you can add custom styling for that specific instance through the Advanced pane at the right side of Assemble Document. ## Checking whether multiple languages are being exported `@multi-language` returns `true` when the document is currently exported (to MS Word or PDF) in multiple languages. You may, for example, use this special function to only show a warning such as “*Please note that even though this document contains both English and German content, only the German content is legally binding.”* when the document is effectively printed in multiple languages. ## Showing a concept-label in a specific language Sometimes a clause in a multi-language document may need to refer to a specific concept-label or datafield in another language. For example, in a signature box (for which the *Don’t translate in multi-language output* is enabled, as per the discussion above) you may want to insert the title of the chairman in multiple languages. For such situations, `@in-language` will be of great help: `#president / @in-language(#president, "en")` Similarly, you may want to print a certain city (inserted by the end-user as a multi-language answer in the Q\&A) in two different languages next to each other: `#signature^location / @in-language(#signature^location, "en")` ## Disabling languages For both technical performance and content management reasons, each Clause9 server is dynamically configured to support a certain number of languages. For example, *fr.clause9.com* supports French and English, while *eu.clause9.com* currently supports 22 different languages and *int.clause9.com* even supports 27 different languages. While some customers may require simultaneous access to all those languages, most users will want to work with only a subset of those languages. Clause9 therefore offers support for disabling languages, in multiple locations. {% hint style="info" %} Note that **disabling a language will never physically remove contents from the server.** Depending on the location where you disable certain languages, you will only cause certain content to become unavailable or (temporarily) hidden. This means that the unavailable/hidden content will re-appear when you extend the number of languages. {% endhint %} ### Disabling languages at the user level In the user’s account preferences, you can enable/disable and reorder the languages made available to the user. The list of languages selected here will be used as the basis to determine which languages to show/hide in Assemble Document, Q\&A and at the clause level.
### Disabling languages in Assemble Document In the *Document* or *Binder* panel you can enable and disable languages for a particular Document or Binder. In addition, you can choose which language should be displayed when the Document/Binder is opened by a user. Note that **the only effect** of disabling a language here, is that a language will **disappear from the languages dropdown in the toolbar**. At the level of an individual clause, you will continue to see all the languages that are enabled by the user. (After all, it may be the case that you are composing a document for use in three languages, using clauses that happen to be translated in many more languages.)
### Disabling languages in a Q\&A In the *options* panel of the Q\&A, you can specify which languages should be available to the end-user — both with respect to the user interface (cards & questions) and for the actual document contents.
* Checking or unchecking **output** languages will avoid that users can output documents in this language. On a practical level, this means that the dropdown menu in the *Document language* question — which you can insert similar to how a text-based or number-based question is inserted into a Card— will only show the selected languages. * Checking or unchecking **cards & questions languages** will cause the language-submenu of the button in the upper-right corner to show only the selected questions. If you want to completely disable the possibility for the end-user to export multiple languages, you can instead check the *Multi-language export* option at the bottom of the options panel of the Q\&A.
# Clauses - FAQ
Help! I inadvertently clicked the lock symbol As explained in another FAQ, clicking the lock symbol **allows** you to take certain actions (e.g., inserting or reordering clauses). **However, until you effectively save the Document/Binder, no changes will have been made to the Document/Binder.** The actual un-linking and de-structuring of the individual clauses will only happen at the moment that you actually save the Document/Binder; as long as you have not done so, you can always try to undo your operations and go back before the moment you clicked the lock symbol (or you can close the Document/Binder and disregard any changes). In fact, even at the moment you hit save, the link between the Binder and its Documents (or between a top-clause and its subclauses) will only be broken if you effectively made changes to the structure. At the moment you perform the save operation, the server will perform an exhaustive comparison between the old and the new version of the structure; if that structure is the same, then no “unlocking” will happen at the server level. There are two ways to check whether the link still exists, or whether it is effectively broken at the level of the server: * you can re-open the Binder and check whether the lock is (still) there * you can inspect the inner contents of the file structure by hitting the icon at the right side within Browse Files ![](/files/gGZ0DGjmSywtCugR81V9) The inner contents of the Binder above will then be shown. In the screenshot below, you can see that file “new binder” has two “proxies”, i.e. pointers towards inner subdocuments saved elsewhere. If a proxy is shown in **light green**, then it concerns a “full proxy” that preserves the link between the Document and its clause structure (i.e., the link is not broken — if you would open the Binder, you will see that the lock icon will appear). ![](/files/wAJzlXHxAeoTvYQN0o4o) However, if you would unlock the first subdocument in the Binder, make certain destructive changes (such s reordering the individual clauses) and then hit save and re-inspect the contents of the Binder, you will see that the proxy towards subdocument “xx” has turned **light blue**. This means that the structure of that subdocument is effectively broken up.
Can I make a library clause conditional without affecting other documents? Yes, you can. However, making a change to a library clause applies that change to all uses of the clause. Not only all future uses, but also all uses of the clause in existing documents as well. That is why it can be dangerous to change a library clause. There is, however, a way to work around this to make your entire clause conditional for your specific document. 1. Insert the clause into your document. 2. Select it and click the pencil icon, then click *“convert to independent ad hoc clause”.* 3. Add the [condition](/clauses/writing-conditions) you want to the “[enabled?](/clauses/enabled)” property of the ad hoc clause. 4. Hit Save. After going through these steps, your clause should have become conditional (using the condition in the ad hoc clause). You can do this for a clause, subclause or even clauses used in an enumeration/bullet list. **Alternatively**, you can consider adding an empty ad-hoc clause (i.e., making sure the clause has no title or body text), adding your condition to that empty clause, and then making the library clause a child of the empty clause. Because child-clauses of a disabled clause will not be shown, this will effectively disable your intended clause as well. *Note that an empty clause will be shown with dotted lines.* ![](/files/LjcBdcQieCme5Ko30yAL)
Should I make one highly automated clause or two or more alternative clauses instead? When faced with a complex clause containing many options, you can either: * make a highly automated clause the text of which varies on the basis of the input assigned to datafields, its context, other clauses implemented in the document, etc., or * make multiple alternative versions of the same clause instead. The preferable option depends on a number of variables. For example, your company’s policy may prefer one option over the other. An important consideration as well is whether the clause(s) should be capable of being used in many different contexts. If that is the case, it may be preferable to split the clause in a number of alternatives without relying too heavily on the context where it will be included or on very document-specific concepts/datafields. On the other hand, a highly automated clause may be easier to build a questionnaire around as use can be made of the batch create mode of Design Q\&A. Finally, consider the end users of the clause(s) as well. Some users may prefer to choose between a number of alternatives as opposed to one clause that adapts automatically, while some (non-legal users, for example) may prefer to have it the other way around.
What is the difference between library clauses and ad-hoc clauses? **Library clauses** are stored in some clause library and can be reused from document to document. For information on how to create library clauses, click here. You can store clauses in different clause libraries: either your personal library, or your organisation’s central library, or the library of one of the departments/groups you are a member of. More information. **Ad-hoc clauses** are document-specific clauses that only appear in the document in which they are created. For more information on how to create ad-hoc clauses, click here. You should only rely on ad-hoc clauses if the clause you are drafting is so specific that you know you will not be using it in other documents. If there is a possibility that you would use it in other documents, it is better to save it in your personal library so that you can still access it but your organisation’s library does not suffer from the clutter.
Can the same clause be used throughout my organisation? Yes, technically this is easily possible. While many clauses will probably be written with one specific team or department in mind, one can imagine a number of clauses that are useful to everyone. Typical examples would be a clause containing a signature block or a governing law clause. Technically, for a clause to be available to all users of a specific customer, that clause should be located in a library that all users have “use” rights to. If there is no such library currently in your organisation, please contact your administrator. From a legal perspective, we would however want to warn for not becoming too enthusiastic about the possibility to share clauses across departments in different legal domains. In theory, it seems attractive to draft a single clause that works for very different domains, but in practice this goal has been the reason why many templating/standardisation projects have failed. We have heard countless stories about lawyers who tried to draft a template that would please everyone. Even when these lawyers were from the same department, this resulted in significant discussions about even the simplest clauses (such as applicable law or party descriptions), e.g. because two partners had strong but opposing views about certain wording. Ultimately, legal drafting is complex and nuanced. Clause9 was developed to allow different legal experts to choose different clauses. As suggested above, clauses that will be shared across departments, will probably be limited in amount.
Does an attribute of a file have an effect on a document? No. Attributes make it easier for a user to find the right clause for his situation. Attributes do not affect how a clause or document will look.
Why is my clause displayed in red even though it has a translation? When you switch the language of a document, what really happens is that all the clauses of the document are switched to the language version you have chosen for the document. If a clause does not have a translation for this particular language, it will be shown in brown/red. If any concept labels contained therein also lack a translation, they will be receive a pink error notification. For example: ![](/files/dcE2dyhPITvXY4A0PT1K) \ If you notice that your clause does have a translation but it is still being displayed as if it does not, this usually means that the title under which it is grouped does not have a translation. Fixing the content title of a clause is usually the right answer for this.
# How to: clauses * [Create signature blocks](/clauses/how-to-clauses/creating-signature-blocks) * [Create advanced party introduction clauses](/clauses/how-to-clauses/creating-advanced-party-introduction-clauses) * [Create a list with body predefined options & free input](/clauses/how-to-clauses/creating-a-list-with-both-predefined-options-and-free-input) * [Create an ad-hoc clause](/clauses/how-to-clauses/create-an-ad-hoc-clause) * [Automatically numbered annexes or schedules](/clauses/how-to-clauses/automatically-numbered-annexes-or-schedules) * [Make a clause repeat](/clauses/how-to-clauses/make-a-clause-repeat) * [Reuse any clause in a different context](/clauses/how-to-clauses/reuse-any-clause-in-a-different-context) * [Setting MS Word document properties](/clauses/how-to-clauses/setting-ms-word-document-properties) * [Electronically sign documents](/clauses/how-to-clauses/electronically-signing-documents) * [Define alternative clauses](/clauses/how-to-clauses/defining-alternative-clauses) * [Make a paragraph within a clause conditional](/clauses/how-to-clauses/make-a-paragraph-within-a-clause-conditional) * [Use a shortcut to refer to a concept](/clauses/how-to-clauses/use-a-shortcut-to-refer-to-a-concept) * [Insert a line break or page break](/clauses/how-to-clauses/insert-a-line-break-or-page-break) * [Creating cross-references](/clauses/how-to-clauses/creating-cross-references) * [Add action buttons to clauses](/clauses/how-to-clauses/add-action-buttons-to-clauses) # Create an ad-hoc clause Ad-hoc clauses are stored in a specific document as opposed to your organisation’s clause library. To create an ad-hoc clause, you therefore first need to open a document to create it in. With your document open, first click the clause you want the ad-hoc clause to appear under. If you do not select a clause, it will automatically appear as the last clause in the document. Click at the top left-hand of your screen and select *New ad-hoc clause*. Fill out the content body of the clause and optionally give the clause a file name before pressing to save your clause. # Create a library clause There are two ways to create library clauses: 1. Via the Browse Files menu 2. Via the Assemble Document menu ## Via the Browse Files menu Go to *Browse files* by clicking at the top of your screen. From there, navigate to the correct folder by first choosing the proper library on the left-hand side of the screen, i.e.: either the organisation-wide library, a specific group’s library of your private library.
Double-click the correct folder, if any, to navigate into it. When you have arrived at the correct location to create your clause, click and then to create the clause. Assign the clause a file name and click to save it. ## Via the Assemble Document menu Go to the *Assemble document* mode by clicking at the top of your screen or open an existing document from your library. First select the existing clause you want your new library clause to be created under, then press the icon at the top left of the screen and select *New library clause.* From the menu that pops up, navigate to the correct folder by first choosing the proper library on the left-hand side of the screen, i.e.: either the organisation-wide library, a specific group’s library of your private library.
Double-click the correct folder, if any, to navigate into it or simply select it by clicking once and then press to drop the clause into that folder. From the edit menu on the right hand side of your screen, assign the clause a file name and click to save it. # Make a clause repeat You may want to add a clause that repeats itself, for example for the party descriptions or signature blocks. Instead of having to add these clauses separately manually, Clause9 can do this for you by using the “repeat clause” functionality in the *Advanced* tab of the *Assemble Document* mode. The *Advanced* tab will become visible when you select the clause you want to repeat. Scroll to the following part:
The drop-down list under “repeat clause” will show a list of all “list of texts”, “number” or “repeating list” [types of datafields](/datafields/types-of-datafields) included in the document. The clause will then be shown as many times as the number of items contained in the selected datafield. If, for example, the datafield “name” of the concept “party” is a repeating list that is selected under “repeat clause”, and three items were inserted into “name”, the clause will be shown three times. Typical use cases for this functionality are party description clauses and signature blocks which can be repeated for as many times as there are parties. # Make a paragraph within a clause conditional To show or hide a paragraph or bullet, based on the (non-)fulfillment of a condition, follow these steps: 1. type the paragraph number or bullet asterisk 2. write the condition elements based on which the text will appear or disappear 3. write the text of the paragraph/bullet In practice, that could look something like this: {% code overflow="wrap" %} ``` 1. This paragraph is not conditional. 2. {#employee^name = "John": This paragraph is only shown if the employee's name is John.} * {#employee^function = "CEO": This bullet is only shown if the employee is the CEO} ``` {% endcode %} {% hint style="warning" %} Make sure not to put the number or asterisk preceding the text of the paragraph or bullet, respectively, inside the condition, as Clause9 will be unable to recognise that these symbols mean the start of a paragraph or bullet and will instead think they are merely ordinary text. {% endhint %} # Use a shortcut to refer to a concept Let’s say that your concept’s file name is very long, e.g. *non-sollicitation-senior-management-key-employees*. It then becomes rather burdensome to refer to it in the Clause9 grammar by using the full file name every time. You can make your life easier by typing a shortcut or abbreviation of your choice in the clause editor, e.g. `#non-sollicitation-smke`. Clause9 will initially not recognise the concept as there is no file name corresponding to it and will therefore display the concept in red below the text field. Using the button however, you can ‘teach’ Clause9 that this abbreviation refers to a concept of your choosing. Browse to your concept and click *select concept*. From now on, when typing `#non-sollicitation-smke` Clause9 will automatically make the link between your abbreviation and the original concept. # Insert a line break or page break ## Line break Line breaks are inserted by using the [special code](/clauses/special-codes) `%%`. The text after `%%` will start on a new line. This command will not insert a new paragraph. However, by inserting multiple line breaks a new paragraph can be created. ## Page break There are two ways you can implement a page break. The first way is to use a setting which will be applied and saved at the document level and the second way is tied to a clause and will therefore be applied to all documents that clause appears in. ### Page break to be applied in one document only Select the clause that you want to appear on a new page and navigate to *Advanced* *> Layout.*
Multiple layout options for the selected clause will appear. By way of a reminder: it may seem like some of the options under *Advanced* and under *Styling* are overlapping. However, there is a difference between those two settings: changes made under the *Styling* tab will be applied to the **whole document.** Under the *Advanced* tab, any changes will be applied to the **currently selected clause**. A walkthrough of the *Advanced* tab can be found [here](/assemble-document-operations-panel/advanced-pane). Under *General*, tick the box that says . In the document, a blue dotted line will appear in place of the page break. The page break will be inserted right before the clause you selected. ### Page break to be applied to all instances of a clause If all instances of a clause should be accompanied by a page break, there are three ways of doing this: * apply custom styling * use the special code `% page break before %` * use the special function @page-break ### **Custom styling** Edit the clause that should have a page break inserted **before** it. Go to in the menu on the right, click on *Custom styling* at the right, navigate to *Title* and then click on the green *+ Custom styling* button.
Scroll down to *Text flow settings of each paragraph* and enable *Page break before* by clicking the slider and then click the checkbox to enable it.
You could also insert a page break before **every single paragraph** of a clause by enabling the same setting outlined above under “non-title parts” of the custom styling settings. ### **Special code** If you insert the [special code](/clauses/special-codes) `% page break before %` before any paragraph, ClauseBase will insert a page break before that paragraph. That also means that inserting this special code before the text in the clause’s *content title*, means the page break will be inserted before the clause, including its title. Using this special code will thus give you some flexibility in choosing where the page break should be inserted – whether before the title or before any other paragraph of that clause. ### Special function The special function [@page-break](/special-functions/special-items-1#page-break) will insert a page break at the location the special function is 'invoked'. This is therefore the most flexible option, enabling you to choose the exact location in a clause or document for the page break to be inserted. {% hint style="warning" %} Note that the special function @page-break can not be used in a table. If @page-break is included in a table, Clause9 will simply ignore it and output the table without a page break. {% endhint %} # Creating a list with both predefined options and free input 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” ### Setting up the clause 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: {% code overflow="wrap" %} ``` 1. #Lender's obligations under #°loan-agreement are subject to the fulfilment of the following conditions precedent: ``` {% endcode %} ### Creating the list structure 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](/datafields/types-of-datafields) to enable the user to choose multiple options, and * a form of [enumeration](/datafields/types-of-datafields) 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](/special-functions/introduction). Check out the [documentation](/clauses/enumerations) 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. #### Tailoring the subparagraphs with predefines 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: {% code overflow="wrap" %} ``` 1. #Lender's obligations under #°loan-agreement are subject to the fulfilment of the following conditions precedent: * AND * {"corporate-docs" in #loan-agreement^conditions-precedent: a resolution of the board of directors of #borrower approving the transactions contemplated by #finance-document} * {"security-docs" in #loan-agreement^conditions-precedent: certified copies of #security-document, validly executed by #borrower} * {"legal-opinion" in #loan-agreement^conditions-precedent: a legal opinion from #borrower's legal counsel confirming that #borrower validly entered into #finance-document and that #finance-document are binding upon #borrower} ``` {% endcode %} 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. ### Fine-tuning clause grammar Our clause grammar looks like this at the moment: {% code overflow="wrap" %} ``` 1. #Lender's obligations under #°loan-agreement are subject to the fulfilment of the following conditions precedent: * AND * {"corporate-docs" in #loan-agreement^conditions-precedent: a resolution of the board of directors of #borrower approving the transactions contemplated by #finance-document} * {"security-docs" in #loan-agreement^conditions-precedent: certified copies of #security-document, validly executed by #borrower} * {"legal-opinion" in #loan-agreement^conditions-precedent: a legal opinion from #borrower's legal counsel confirming that #borrower validly entered into #finance-document and that #finance-document are binding upon #borrower} ``` {% endcode %} 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: ``. Implementing this for our specific grammar, we get the following result: {% code overflow="wrap" %} ``` 1. #Lender's obligations under #°loan-agreement are subject to the fulfilment of the following conditions precedent: * AND * {"corporate-docs" in #loan-agreement^conditions-precedent: a resolution of the board of directors of #borrower approving the transactions contemplated by #finance-document} * {"security-docs" in #loan-agreement^conditions-precedent: certified of <#security-document>, validly executed by #borrower} * {"legal-opinion" in #loan-agreement^conditions-precedent: a legal opinion from #borrower's legal counsel confirming that #borrower validly entered into #finance-document and that <#finance-document> binding upon #borrower} ``` {% endcode %} 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. ### Building the free input option 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. #### Can we use the existing datafield? 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.: {% code overflow="wrap" %} ``` * AND * {"corporate-docs" in #loan-agreement^conditions-precedent: a resolution of the board of directors of #borrower approving the transactions contemplated by #finance-document} * {"security-docs" in #loan-agreement^conditions-precedent: certified of <#security-document>, validly executed by #borrower} * {"legal-opinion" in #loan-agreement^conditions-precedent: a legal opinion from #borrower's legal counsel confirming that #borrower validly entered into #finance-document and that <#finance-document> binding upon #borrower} * #loan-agreement^conditions-precedent ``` {% endcode %} 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. #### Using a separate datafield 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](/special-functions/introduction). 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: {% code overflow="wrap" %} ``` 1. #Lender's obligations under #°loan-agreement are subject to the fulfilment of the following conditions precedent: * AND * {"corporate-docs" in #loan-agreement^conditions-precedent: a resolution of the board of directors of #borrower approving the transactions contemplated by #finance-document} * {"security-docs" in #loan-agreement^conditions-precedent: certified of <#security-document>, validly executed by #borrower} * {"legal-opinion" in #loan-agreement^conditions-precedent: a legal opinion from #borrower's legal counsel confirming that #borrower validly entered into #finance-document and that <#finance-document> binding upon #borrower} * @bullets(#loan-agreement^conditions-precedent-free) ``` {% endcode %} Any inputs added to `#loan-agreement^conditions-precedent-free` will be added as separate bullets on the same level as our predefined bullets. #### Why did we not use {AND! | … | …}? 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. # Defining alternative clauses {% embed url="" %} In Assemble Document mode, the alternative symbol shows you which alternatives are available for a given clause. Clicking this symbol gives you a shortlist of available alternatives which you can then insert by simply clicking one. {% hint style="info" %} If this symbol is not visible, you must enable it in the document’s options menu at the right side. {% endhint %} But how do you designate which clauses are linked together as alternatives? Start by opening a clause in the clause editor, then navigate to the *links* tab on the right-hand side. Click the button. This will open a prompt allowing you to navigate to the clause you wish to indicate as the alternative. Do so and when you have found it, select to create a link between the two clauses. What you see then should look something like this example:
Note that ClauseBase recognizes the fact that you have linked two clauses together and so will automatically designate the two as alternatives since that is the only relation two clauses can have. If on the other hand you would like a concept to a clause, you could choose between different possible relations. Also note that the link created in this example designates an outgoing link from the seller-friendly clause to the buyer-friendly clause. If you take a look at the *links* tab from the clause you linked to, in this case the buyer-friendly version of the clause, you will see this:
This “incoming link” shows you the link that was made from the seller-friendly clause and also shows you that the relationship with this clause is that is is an alternative of the former. This way you do not have to make the connection from the two sides. # Creating cross-references {% embed url="" %} Clause9 distinguishes between three different kinds of cross-references: * To a clause within **the same clause file** * To another clause **within the same document** * To a document **within the same binder** {% hint style="info" %} Cross-references to a document within the same binder are also the topic of [another article](/binders/cross-references-between-documents). {% endhint %} ## Cross-references within the same clause file {% code overflow="wrap" %} ``` 1. Alpha 2. Beta * element 1 * element 2 * element 3 ``` {% endcode %} ### **Numbered sub-clause** `§number` is used to refer to a numbered sub-clause within the same clause file. For example, use `§2` to refer to `2. Beta`. In the document, it will say *Clause 2*. Under the *reference styling settings*, you can change the word used for “Clause” in the document (e.g. “Article” or “Section”). ### **Clause as a whole** `§this` is used to refer to the current numbered subclause. `§this-title` refers to the title of the entire clause. In the above example, if you were to insert `§this` into 2. Beta, the reference in the document would show as *this Clause 2.* By inserting `§this-title` into `* element 1`, Clause9 will convert the code to *this Clause 2* since *Clause 2* is the associated clause title. If the title is currently not visible, an error will appear. ### **Bullets** If you created a regular bullet list (using asterisks), referring to the previous bullet is done with the command `§*-`, the next bullet with `§*+` and the current bullet with `§*`. More information on how to create enumerations can be found [here](/clauses/enumerations). ## Cross-references within the same document or binder There are two different methods of cross-referencing: * One-time reference to another clause using cross-tags * Content-based reference to another clause using concepts This type of cross-reference will work both when the target clause is located in the same document and when it is located in another document of the same binder. ### **Cross-tags** This allows you to insert a reference to another clause using its cross-tag. In order to insert a cross-tag, first, navigate to the clause the reference should be directed to. The cross-tag-name is assigned under cross-tags and entered by hitting the enter key.
Now, the cross-tag can be inserted in the clause content body by typing `§cross-tag-name` (e.g. `§this-is-the-cross-tag-name`). ### **Concepts** This command allows you to insert a reference to the first clause in the document that implements a specific concept. Concepts are implemented under the links tab of a clause.
In order to insert the reference, type `§#concept` (e.g. `§#client`). It is highly prefereable to use cross-tags to insert cross-references. Unless there is a good reason to use a concept (e.g. the target clause already implements a certain existing concept), cross-tags should be used. Cross-tags are much faster (in terms of document loading time) and do not require a separate file to be created in the clause library. ### Cross-references to another document in the binder Inserting a cross-reference to another **document** in the binder is very similar to inserting a cross-reference to a clause. A document can contain cross-tags or implementing links to concepts much like a clause can. In the *Binder* panel, click the *Properties* button at the button and then click the target document (the document you would like to refer to) in the pop-up menu.
Now you will be able to edit that document’s properties. Insert a cross-tag (or an implementing link to a concept), similar to [creating a cross-reference to another clause](#clause), and save the document by clicking *save in library* or *update adhoc doc* (as relevant). ### When to use concepts and when to use cross-tags? Which of the two approaches you should use, mainly depends on the question whether you are already using that concept as a defined legal term in the document. If that is not the case, then it’s much faster to use a cross-tag reference, as this avoids that you have to create a new concept. It also avoids that you litter your database with single-use concepts. Furthermore, cross-tags are a lot easier to process for Clause9 so especially when you are working in long, complex documents, performance will be significantly increased if you primarily rely on cross-tags as opposed to concepts. # Creating signature blocks {% embed url="" %} 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. {% hint style="info" %} The video above is a more basic introduction to signature blocks and therefore does not follow the structure of the article below. {% endhint %} ## 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](/clauses/introduction-to-tables) 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](/clauses/introduction-to-tables), that would look as follows: {% code overflow="wrap" %} ``` || || || || || || || || || || || || ``` {% endcode %} 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](#populating-table). ### Creating concepts and datafields #### **Creating a concept & concept label** [Concepts](/concepts/introduction-to-concepts) can be [created in various ways](/concepts/creating-concepts). 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](/datafields/introduction-to-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](#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: {% code overflow="wrap" %} ``` || #Lessor || || || || || || Name: #lessor^representative1-name || Name: #lessor^representative2-name || || Title: #lessor^representative1-title || Title: #lessor^representative2-title || ``` {% endcode %} **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](/clauses/writing-conditions) 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: {% code overflow="wrap" %} ``` || || {@assigned(#lessor^representative2-name)} || || #Lessor || || || || || || Name: #lessor^representative1-name || Name: #lessor^representative2-name || || Title: #lessor^representative1-title || Title: #lessor^representative2-title || ``` {% endcode %} ## 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](/clauses/special-codes) for more information. {% code overflow="wrap" %} ``` || || {@assigned(#lessor^representative2-name)} || || #Lessor || || || % signature % || % signature % || || Name: #lessor^representative1-name || Name: #lessor^representative2-name || || Title: #lessor^representative1-title || Title: #lessor^representative2-title || ``` {% endcode %} Alternatively, you could make use of the *@tab-u* [special function](/special-functions/introduction) 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](/files/custom-styling) of the clause containing the table or by adding [deviating styling](/clauses/deviating-table-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: {% code overflow="wrap" %} ``` || % 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 || ``` {% endcode %} ## 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](/datafields/types-of-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. # Creating advanced party introduction clauses Clauses introducing the parties to a contract or other legal document are often some of the more complex clauses you can draft in Clause9. This is because there are an enormous amount of permutations clauses like these can have. Below, we will create a party introduction clause for a sale and purchase agreement in which there is at least one seller and at least one purchaser, with the option to designate additional ones. Each seller and each purchaser can in turn be either a legal person or a natural person and different datafields should be shown depending on this qualification (e.g.: a natural person does not have a company number). {% hint style="info" %} 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. {% endhint %} ## Setting up the structure First, we must decide how we will structure the party introduction. Two things are important to take into account here: 1. We know that there are 4 basic permutations of the parties, i.e.: (i) seller – legal person, (ii) seller – natural person, (iii) purchaser – legal person, and (iv) purchaser – natural person 2. We need to be able to repeat these 4 basic permutations with differing input depending on the user’s preference. For each individual permutation, we will have to create a separate clause and then enable/disable/repeat them as is necessary. This means we will be working with [repeating list datafields](/datafields/repeating-list-datafields). For a primer/reminder on how these work. This also means we will be working with the [“enabled?” tab ](/clauses/enabled)of the clause files. Below, we go through the example for the seller – legal person and seller – natural person. This exercise can then be repeated for the purchaser – legal person and purchaser – natural person. ## Creating the content of the clauses Let’s start by creating the first two permutations: the seller – legal person and seller- natural person. Navigate to the *assemble document* menu and open an empty document. Create new library clause by clicking the button, selecting *New library clause* and navigating to the desired folder to place it in then repeat this exercise for the second clause. The final product for these clauses could look like this: | **Seller – legal person** | **Seller – natural person** | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | | *\* Acme Ltd, a company incorporated in Belgium, having its registered office at Church Street 4 and registered with the Crossroads Bank for Enterprises under company number 12345689, duly represented for the purpose of this Agreement by John Doe, CEO*; | *\* Jane Doe, born on 1 January 1985, national registry number 123456789, residing at Church Street 4, Belgium;* | Transformed to ClauseBase grammar, they would look something like this: | **Seller – legal person** | **Seller – natural person** | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `* #seller^company-name #seller^company-type, a company incorporated in #seller^country-of-incorporation, having its registered office at #seller^seat-address and registered with #seller^national-company-register under company number #seller^company-number, duly represented for the purpose of #°contract by #seller^representative-name, #seller^representative-function` | `* #seller^first-name #seller^last-name, born on #seller^date-of-birth, national registry number #seller^national-registry-number, residing at #seller^residence-address, #seller^country-of-residence` | If any of these datafields have already been assigned in your Clause9 library and are not repeating list datafields, please choose different ones. It is important to create new datafields, as will be demonstrated below. For the repeating list datafields to function propertly, it is important **not** to reuse datafields between the legal person clause and the natural person clause. Otherwise, it will be difficult to assign the proper datafield to the proper clause. Create the concept `#seller` by clicking the red error notification (assuming this concept does not already exist in your library), clicking “*create a new Concept*“, and navigating to the desired folder to place it in. Next, each individual datafield should be created and designated as a repeating list datafield. To do this quickly, simply click a datafield as displayed in red next to the concept and select *repeating list*. The reason we are creating repeating list datafields and not text datafields is because we know that there may potentially be two or even more legal person sellers. We want to be able to fill information like the company name out multiple times instead of only once. When you have created each individual repeating list datafield, navigate to the concept file of “#seller” by Alt + clicking (Windows) or ⌥ + clicking (MacOS) it. Then, for each individual datafield, you need to assign the type of repeating list it will be. For the datafields that we have assigned, change *element type* to text for all of them except for `#seller^date-of-birth`, which should have the element type “date”. ## Repeating the clauses Next, we need to designate the datafield which will cause the clauses to be repeated. It makes sense to choose the company name/first name for the legal person/natural person respectively as the clauses need to be repeated for each name that is filled out. Select the “seller – legal person” clause in the interactive preview on the left-hand side of the screen and navigate to the *advanced* tab of the operations panel. Under the dropdown menu of heading “*repeat clause*“, choose the company-name datafield. Do the same for the “seller – natural person” clause but choose the first-name datafield. Activating this *repeat clause* option means that every single time a new name is filled out, the clause will be repeated and the datafields therein will be filled with the values that have been provided for each entry. For example, if you fill out three names, there will be three entries under the datafields tab of the operations panel. If you then start filling out addresses, the first address entry will follow the first name entry, the second address entry will follow the second name entry and so on. ## Enabling/disabling the clauses Your clauses are now capable of being repeated for as many parties as you wish to identify. However, both the “legal person” and the “natural person” clauses are always visible under the current set-up. What if, for example, there are only legal persons in the document you want to create? For this, you need to define a condition that enables the clause upon fulfillment. For each individual clause, open up the file by double-clicking the preview on the left-hand side of the screen then navigate to the “*enabled?*” tab of the clause file. The condition that we need to input here should essentially say *“only if a company/first name of a legal/natural person has been filled in, can this clause be shown.”* To achieve this, we will make use of the `@assigned` [special function](/special-functions/introduction). This function will evaluate whether a datafield was assigned a value or not and will on that basis return true or false: | **Seller – legal person** | **Seller – natural person** | | --------------------------------- | ------------------------------- | | `@assigned(#seller^company-name)` | `@assigned(#seller^first-name)` | ## Finishing up When you have performed the above steps, you can test out what you have created by going to the datafields tab of the operations panel and interacting with the datafields you have created. You should be able to see the following: * Both clauses are disabled by default (since no name has been entered yet). * Entering in a single seller – company name enables the seller – legal person clause and fills out the company name. * Entering additional company names repeats the seller – legal person clause as many times as you entered in company names. * The same goes for the seller – natural person clause. If the clauses react the way they should based on your input, you can repeat the exercise for the purchaser clauses by copying the content of the seller clauses and replacing `#seller` with `#purchaser`. ## Creating a Q\&A with repeating list datafields Repeating list datafields are unique in the way that they need to be shaped in *Design Q\&A* mode. Unlike other datafields, you cannot use *Batch create* to create questions or cards with them. Instead, you need to use the or buttons and then select *table*. Note: the icon next to “table” is the same icon as that of repeating list datafields. For the purpose of this tutorial, let’s create a new card for each clause. To do so, follow these steps: * Create a card with a table by clicking and then *table*. * Name the card (e.g.: “Seller – legal person”) and the question (e.g.: “Identification information”). * Select the question and click on the button. * Click the button as many times as there are datafields in the seller – legal person clause. * Assign a datafield to each individual column with the help of the dropdown menu. * Repeat this exercise for the three other clauses. # Automatically numbered annexes or schedules {% embed url="" %} In many documents, annexes/schedules must be added based on certain options or clauses being chosen in the main body of the document. A good example would be a consent form annex to a share transfer agreement, which is what we will be implementing here. We want the consent form to be included if the share transfer agreement contains a clause requiring a consent form to be included. The annex must also be included if the target company is a company type to which transfer restrictions apply by law. For this latter category, we will take as an example the Belgian law BV/SRL (*besloten vennootschap/société à responsabilité limitée*). {% hint style="info" %} 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. {% endhint %} ### Starting materials Prior to starting this tutorial, please create the following concepts if you do not have them yet: * `#buyer`, concept label *buyer* * `#seller`, concept label *seller* * `#company`, concept label *company* and datafield named *company-type* with one predefine: *BV/SRL* * `#agreement`, concept label *agreement* Make a clause with *content title* “Consent” and the following *content body*: {% code overflow="wrap" %} ``` 1. On the date of #°agreement, #seller will provide #buyer with the consent letter in the form as attached hereto as Annex Form of Consent Letter. ``` {% endcode %} Create a new document with document title “Share Transfer Agreement”. The document title can be configured under the [document pane](/assemble-document-operations-panel/document-pane) of the Assemble Document [operations panel](/assemble-document-operations-panel/operations-panel). Create another document with document title “Annex Form of Consent Letter”. While in a real situation we would add clauses to this document, for the purposes of this tutorial we will leave it empty. ### Creating a binder In order for the end user to be able to generate several documents in one go (even having the option to create separate Word files or PDFs), we have to include these documents in [a binder](/binders/binders-general). A binder is created by choosing in the top right corner and choosing *New Binder*. Go to the [binder pane](/assemble-document-operations-panel/binder-pane) and add both the Share Transfer Agreement and the Annex Consent Letter using the button. The Share Transfer Agreement will function as the main body so we can check the option under the Share Transfer Agreement document. ### Making the annex conditional How can we make sure the annex only appears when required? As a reminder, these are the conditions on which the annex should appear: * the consent clause was implemented; or * the company type of the target company is BV/SRL. In Clause9 grammar, the second condition is easy to implement: `{#company^company-type = "BV/SRL"}`. But how can we implement the first condition? There are two ways of doing this. Either we add [an “implements” link](/clauses/links) to a concept to our clause, or we add a so-called *cross-tag*. The [Cross-references article](/clauses/cross-references) provides some guidance on when to use the link and when to use cross-tags. For the purposes of this tutorial, we will be using a cross-tag. Edit the “Consents” clause you created in the beginning. Navigate to *cross-tags* in the navigation menu on the right. Add “consent-required” as a cross-tag and press Enter. To make the annex subdocument conditional on the clause with the cross-tag being included and visible in another subdocument in the binder, we can make use of the `@crosstag-implemented` [special function](/special-functions/introduction). This function takes a cross-tag and checks whether the document or binder contains a clause (that is currently visible) with such cross-tag. If it does, the function returns true. Else it returns false. Let’s implement this. In the binder pane, edit the Annex Form of Consent Letter document properties. You can do this by clicking the *Properties* button under the *Advanced* heading of the *Binder* pane.
Now we can edit this subdocument’s properties. Go to *Enabled?* in the navigation menu on the right and write the condition using the `@crosstag-implemented` special function. It will look like this: {% code overflow="wrap" %} ``` @crosstag-implemented("consent-required") ``` {% endcode %} In the *enabled?* section, conditions are written without curly brackets. As this section can only contain conditions, curly brackets are not needed. However, we want our other condition (i.e. the company being a BV/SRL) to trigger the annex as well. How can we combine both of these conditions? We can make use of ways of combing conditions: [AND, OR or NOT](/clauses/writing-conditions#combining-subconditions-andornot). Consider which one we want to use here. As either of our conditions should trigger the annex, we will make use of OR: {% code overflow="wrap" %} ``` @crosstag-implemented("consent-required") OR #company^company-type = "BV/SRL" ``` {% endcode %} ### Cross-reference to the annex We also want to be able to refer to the annex dynamically in our clause. We can do this by using cross-tags as well (or, again, by creating links). Let’s add a cross-tag to our annex subdocument: “annex-form-of-consent-letter”. Now how do we refer to the subdocument in our “Consents” clause? We make use of the `§` symbol. Let’s implement this in our clause: {% code overflow="wrap" %} ``` 1. On the date of #°agreement, #seller will provide #buyer with the consent letter in the form as attached hereto as §annex-form-of-consent-letter. ``` {% endcode %} ### Document title in cross-references #### Full or short title Under default styling settings the clause text will refer to the annex using its short document title, if there is one. If you have not chosen a short document title, the full title will be used. We can make Clause9 always use the full title by going to the [styling pane](/assemble-document-operations-panel/styling-pane) of the operations panel. Under the tab “references”, you can choose what cross-references look like by changing this setting:
However, let’s keep this setting as it is – using the short title. #### Subdocument numbering One final tweak we can make is giving our subdocument dynamic numbering. Let’s assume our agreement can contain more than one annex. In such case, we will want to number our annexes. But the numbering should of course adapt automatically to annexes being added/deleted. There’s an easy way of doing this in Clause9. Clause9's placeholder for dynamic numbering of document titles is `{1}`. Add `{1}` to the document title you use for cross-references. In your document, `{1}` will be changed to the actual number of the relevant subdocument in the binder. *** There you go – you have now made a binder of two documents where one document will be enabled based on one of two conditions being fulfilled in another document. In practice, these conditions can be anything you want them to be. And you can use more complex combinations of conditions as well. Good luck! # Reuse any clause in a different context Let’s say you are drafting a lease agreement and you are looking for a notice clause. Using the [search functionalities](/assemble-document-operations-panel/search-pane) inside the Assemble Document mode, you find the perfect clause. But there’s one problem. That clause was written for a share purchase agreement, with parties being referred to as the Seller and the Buyer… No problem! In Clause9, you can easily adapt your clause to the document you are drafting by using [mapping](#mapping-concepts). 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. For the purposes of this How To, please create the following clauses and any concepts (with concept labels) and datafields included in there: ## Party description {% code overflow="wrap" %} ``` * #lessor^name residing at #lessor^street-number, #lessor^postal-code #lessor^city (as #lessor); and * #lessee^name residing at #lessee^street-number, #lessee^postal-code #lessee^city (as #lessee) ``` {% endcode %} ## Lease clause Clause title: “Lease” {% code overflow="wrap" %} ``` 1. #Lessor agrees to lease the premises (as described below) to #lessee. ``` {% endcode %} ## Notice clause Clause title: “Notices” {% code overflow="wrap" %} ``` 1. Any notice to be sent to #?party under #°agreement shall be sent by registered mail to the address listed below: 1.1. For #seller: || % align left, borders false, borders horizontal false % || || #seller^street-number || || #seller^postal-code #seller^city || 1.2. For #buyer: || % align left, borders false, borders horizontal false % || || #buyer^street-and-number || || #buyer^postal-code #buyer^city || ``` {% endcode %} Insert both clauses in a new document. ## Using mapping ### Mapping concepts What we want to accomplish now is that the notice clause we inserted refers to “the Lessor” and “the Lessee” instead of “the Buyer” and “the Seller”. This can be done by using a technique called “mapping”. We can make a concept in a clause (or an entire document) map to another concept, i.e. act as if it were another concept. How do we do this? First, select the notice clause, i.e. the clause you want to adapt itself. Selecting the clause will reveal a new pane in the [operations panel](/assemble-document-operations-panel/operations-panel) on the right: the [advanced](/assemble-document-operations-panel/advanced-pane) pane. This pane has two tabs: *Layout* (selected by default) and *Mapping*. Click on *Mapping*.
In the *Mapping* tab, we can choose to map concepts and datafields. In this case, we want the `#buyer` and `#seller` concepts to act as if they were `#lessor` and `#lessee`. The *Map from* selector lets you choose a concept that should be changed into another concept (selected in *map to*). Let’s start with the `#seller` concept. In *Map from*, select *seller.* In *Map to,* select *lessor*. To apply the mapping from *seller* to *lessor*, click the button. Now check out your clause again. Where it said “the Seller”, it will now say “the Lessor”! Do the same for *buyer* and *lessee*. You will notice that in this case the datafields in `#buyer` and `#seller` were mapped automatically to the relevant `#lessor` and `#lessee` datafields as well. Clause9 will automatically do this if the datafields have the **same name** and are of the **same type**. This underlines the importance of having a consistent naming policy throughout your organisation for concepts and datafields. Datafields will be mapped automatically to other datafields. Datafields can be mapped manually as well if their names are not identical. The mapping tab contains a *map datafields* section under the *map concepts* section. Similarly to mapping concepts, you can select a datafield (in *map from*) that should act as another datafield (in *map to*), i.e. take any inputs given to that other datafield. Mapping datafields will remove the need to enter the same information multiple times in the same document, further adding to time saved by automating your documents! # Setting MS Word document properties In the document properties of a DOCX file, you can specify data such as the author, company, etc. — as well as a variety of other information, such as comments, the relevant manager, and even custom information. ClauseBase supports setting such data through the system of [Global Placeholders](/admin/global-placeholders). Have a look at the section [Using placeholders to set MS Word document properties](/admin/global-placeholders) in particular to learn how to specify such system. Please note that only administrators can currently define these properties. # Add action buttons to clauses {% embed url="" %} Action buttons are an easy way to allow users to add pre-selected clauses with one single click. This is particularly useful if you want to allow the user to individually add clauses of a certain category, like in this example.
## Inserting an Action Button In order to insert an action button, you need to first navigate to the clause where you want the button to appear. Double-click it to start editing it and in the menu on the right-hand side, click on *Action button*.
Add an action button by selecting the green icon. A new window with more options will appear.
* **Button caption**: This is where you insert the text that will be displayed on the button. Different versions can be made for different languages. Translations can also be generated. * **Button position:** The button can be positioned either above, or below the selected sub-clause. * **Button visibility:** This option allows you to hide a button when at least one sub-clause exists. * **Action:** Here, you can choose which clauses should become available by clicking on the button. You can either: * *execute a saved search:* Choosing this allows you to save search criteria. This search will then always be executed when the button is clicked. The search results will be presented to the user * *browse selected folder:* If this option is selected, the user will be taken to the selected folder in the *browse* pane, enabling him to view the contents of that folder and add any clauses in there as relevant * *present preselected clauses:* Lastly, you can also individually select clause which will then be presented by clicking on the action button. # Electronically signing documents Clause9 can prepare documents for electronic signing, and subsequently submit the prepared document to the e-signature provider, such as Connective, Dropbox, HelloSign or Scrive. There are quite some moving parts involved when preparing a document for automated electronic signing. Accordingly, be aware that this is an **advanced subject,** and that your **account profile** needs to support various advanced functions. Also, be aware that **not all Clause9 subscriptions support electronic signing**. ## E-signature terminology By way of introduction to e-signatures, it is important to know a few terms and concepts. (These terms differ somewhat between e-signature providers, but the basic ideas remain consistent.) ### Role of Clause9 Clause9 does not sign any of the documents — this is the role of the e-signature provider, with whom you need a separate subscription. Clause9 merely *submits* a PDF-version of the document to an external signature provider, accompanied by a few extra details, such as the roles and names of the parties involved and the physical location where the signatures must be placed in the PDF document. Once submitted to the e-signature provider, the role of Clause9 in the signing process is over, and you will need to use the e-signature provider’s tools (e.g., its signing portal) to receive signed documents, check the status of signatures, withdraw documents, and so on. None of those functions are offered by Clause9. {% hint style="danger" %} In most typical use cases, Clause9 is therefore only 1/3rd or 1/4th of the entire e-signature workflow you are typically looking for. You may instead want to consider using a Contract Lifecycle Management (CLM) software package, such as [Contractify](http://contractify.io), which usually takes care of the workflow steps after the document was submitted. In many cases, you may even want to switch the submission process, so that Clause9's document is sent to the CLM (which then takes care of the submission to the e-signature provider), instead of having Clause9 submit the document to the e-signature provider. {% endhint %} ### Stakeholders In an esignature process, multiple “**stakeholders**” are present that can have multiple **roles**. In their simplest form, those stakeholders are **signatories**. However, a stakeholder can also **validate** a document (i.e., approving upfront that the document can indeed be signed, or instead rejecting it), and may also be flagged as a person who will **receive** the signed document. For each natural person involved, one or more of those three roles — validating, signing and receiving — will apply. For example, while a credit controller may only *validate* the signing process for a certain document, and a backoffice assistant may only *receive* the signed document, a general manager may simultaneously *sign* and *receive* the document. ### Authentication methods Before a stakeholder can sign a document, she needs to be authenticated by the e-signature provider. Which type of authentication is provided will depend on the e-signature provider and your subscription, but currently the following three options can be activated through Clause9: * **Email authentication** is typically the cheapest and fastest type of authentication, but also (relatively speaking) the least secure of the three authentication methods. Typically the signatory will receive a link or a code through her email address. This link/code then needs to be used in order to login to the e-signing website. * In **SMS authentication**, the e-signature provider will send a code via SMS to the signatory’s mobile phone. Because SMS traffic is more difficult to intercept, this method is a bit more secure than email authentication. However, because of external costs to be paid by the e-signature provider to the telecom provider, it may also be a bit more expensive than email authentication. * **Local authentication types** are the most expensive, but also tend to be the most secure. For example, in Belgium, the [Itsme](https://www.itsme.be/en) authentication method offers an advanced yet user-friendly authentication system through end-user smartphones, that is even trusted for banking transactions. Be aware that these three authentication methods may have different legal implications in certain jurisdictions, due to the different level of security involved. While even the relatively least secure option (email authentication) is — generally speaking — probably more secure than a traditional handwritten signature, courts across the world are very inexperienced in this subject matter, and some tend to frown upon these electronic methods. Some local legislation may also prohibit or mandate certain types of e-signatures, depending on the type of transaction involved. For example, in Belgium, transactions with employees are subject to specific legislation that raises the security bar. ## Set up an integration with an e-signature provider In the dropdown menu below the top right button of your screen, click on *Integrations.* Next, add a *Service instance* for an e-signature provider. In the screen below, we use the example of Connective.
The **General** tab contains only one part that you may want to change: the **Access bundle** setting. It allows you to specify who has access to this e-signature service instance. The other properties can probably be ignored, but for the sake of being exhaustive: * The **Template** allows you to merge different e-signature templates together. This is a very advanced operation, so you can probably keep this set to *no**.*** * The **Description** box allows you to give a title to this service instance. You can fill in anything, as long as it is sufficiently descriptive for you and your colleagues. * In the **Prefix** box you can probably leave the suggested prefix as-is. This is only relevant in very advanced scenarios, where different types of e-signature service would be created. In the **Input fields** sheet you need to your account name (a URL in the case of Connective), password and username — these should have been provided to your by your e-signature provider. In addition, you can choose which signing methods are allowed to be used by end-users. If you disable a signing method here, it will be disabled for all documents and all users. Note, however, that even if you enable a signing method, individual documents may disable it on a case-by-case basis.
The **Input tags** sheet can be ignored for e-signatures. (It is a standard section that is shown for each type of integration, but is not very relevant for e-signatures.) ## Prepare signature blocks in a document Similar to a paper document, you need to reserve some space in your document to actually position the signature of each party. In Clause9, you reserve such space by using the `@sign` special function within a clause — probably as part of a table cell, or some other typical signature clause. For example:
For every person that should sign, you invoke the `@sign` function, with the relevant name as the sole parameter (“employee” and “employer” in the example above). The signature name will be presented to the Q\&A user, so make sure it is sufficiently clear which type of party you are referring to. When submitting the document to the e-signature provider, Clause9 will flag the location where the `@sign` function is used as a relevant signature area. ## Preparing a Q\&A It is not strictly necessary to take special steps to prepare a Q\&A for electronic signing. Assuming that the following conditions are all met, the user can initiate e-signing: * the end-user has the right to electronically sign documents * the end-user is granted access to at least one e-signature service instance (i.e., the *Access Bundle* setting of at least one e-signature service permits access to the end-user) * the underlying document contains at least one `@sign` special function However, when no further preparations are taken, the software will not be able to automatically fill the name and contact details of each signatory. In addition, several configuration options for the e-signature provider will probably not be set in the way you want them to be. Both the contact details mapping and the e-signature provider configuration heavily rely on Clause9's [powerful global placeholders system](/admin/global-placeholders), which offers a refined system for setting default options at many different levels, to facilitate the management of contracts. You must understand this placeholder system before proceeding. ### Mapping contact details For each of the “stakeholders” in the e-signature process, a separate record (i.e., table row) needs to be created as part of the **e-signing global placeholder**: #### **Creating the e-sign global placeholder.** Create a new global placeholder *System-defined > E-signing > E-sign stakeholders*. This is a table-based placeholder with rows & columns. As explained on the [global placeholders page](/admin/global-placeholders), such placeholder can be inserted at many different levels, e.g. at the *customer account* level so that it applies to everyone, or at the *group* level, or at the *individual user* level, or at the level of an individual Q\&A. As this placeholder is table-based, you can even combine rows from multiple levels. For example, you could create an instance of this placeholder at the customer account level, and insert the CEO’s signature details there, so that the CEO’s signature details will always be available. Then, at the level of a group, you could add a particular general manager’s signature details. And at the level of an individual Q\&A, you could even conditionally insert certain rows with signature details, depending on whether certain options are chosen by the Q\&A’s end-user. #### **Configuring the e-sign global placeholder** The software will then create the following list of columns for you:
Column nameData typeExplanation
partytext

The internal name for this party, which will be displayed towards the end-user at the left side of the signatory dialog box.

For signatories, this name must match the parameter specified in the @sign special function, as used in a clause body (e.g. employee or customer). For parties that validate or merely receive the document, you can use any name — as long as it’s unique.

first-nametextThe first name of the natural person who will sign/validate/receive the document.
last-nametextThe last name of the natural person who will sign/validate/receive the document.
emailtextThe email address of the natural person who will sign/validate/receive the document.
phonetextThe cell phone number of the natural person who will sign the document, if the SMS option is chosen as an authentication mechanism (see below).
signingtrue/falseEnable or disable a person’s signatory role. (Note that in order to qualify as a signatory, the party name must also be used in a @sign special function currently present in the document.)
validatingtrue/falseEnable or disable a person’s validation role.
receivingtrue/falseIf set to false, then a person will not receive a copy of the signed document, once all signatories have signed.
disallow-smstrue/falseIf set to false, then the SMS authentication method will be disabled for this person. (Note that the SMS authentication method must also be enabled at the level of the service instance / integration.)
disallow-emailtrue/falseIf set to false, then the email authentication method will be disabled for this person. (Note that the email authentication method must also be enabled at the level of the service instance / integration.)
disallow-itsmetrue/falseIf set to false, then the Itsme authentication method will be disabled for this person. (Note that the Itsme authentication method must also be enabled at the level of the service instance / integration.)
no-email-notificationstrue/false

If set to false (by default it is set to true), then no emails will be sent to notify a person about important events during the signing process.

You typically do not want to set this to false, but there are exceptions. For example, to avoid that your CEO would receive hundreds of individual emails requesting her to sign a certain document (which is unnecessary when she always open the e-signature provider’s signing portal at the end of every working day to perform bulk-signing), you may want to set this to false.

ordernumber

The order in the validation / signing process. If not every party has the number, then higher numbers will get involved at a later stage.

For example, if both the CEO and some general manager must validate a document, and the CEO’s order number is set to 1, while the general manager’s number is set to 2, then the CEO will be invited to validate first. If she would reject the document, then the general manager will not even be asked to approve. If, instead, both the CEO and the general manager are set to the same number (or no number at all), then both persons will be asked to validate at the same time.

#### **Configuration hints:** * Typically you will want to create one row per stakeholder.
* You may want to consider spreading those rows across multiple levels — e.g., both at the customer account level and at the level of an individual Q\&A — and then combine all those rows through the “Append” option for table-based global placeholders). This allows you to ensure that certain signature data will “ripple through” to all the Q\&As.
* Instead of hard-coding fields such as *first-name, last-name, email* and *phone*, you may want to set those cells to *Take value via a question identifier*, and then refer to the relevant question in the Q\&A where that person’s details are filled in by the end-user (or perhaps chosen from a predefine, or from a [spreadbase](/integrations/spreadbases)). You can of course, also link fields such as *signing* and *validating* to Q\&A answers (e.g., because there is some logic involved to determine whether or not a certain party will have to validate), but it is less common to do so.
* Using question identifiers also allows you to reuse change-sets across Q\&As, either by physically copying a *Change placeholder* from one Q\&A to another, or (even better) by [importing such a change as a proxy](/qna/import-pane). If both Q\&As use the same identifiers for the same questions (or even import those questions [through proxy cards](/qna/import-pane)), ClauseBase will insert the answer to those questions into the placeholder’s cells. #### **Additional e-sign options** In addition to the global e-sign table-based placeholder for configuring the individual stakeholders, you may also want to specify the following options, through separate global placeholders: * *System-defined > E-signing > E-sign disallow end-user to change options*. If set to true (the default is false), then a user cannot configure the roles and authentication methods of each stakeholder. This effectively hides the *Show options* button in the bottom-left corner of the e-signature dialog box.
* *System-defined > E-signing > E-sign (Connective) document group code*. This allows you to submit a DocumentGroupCode text to e-signature provider Connective. * *System-defined > E-signing > E-sign (Connective) initiator email*. This allows you to set the email address of the person who submits the document to Connective (the “initiator”). When not set, the email address of the end-user’s ClauseBase account will be used. ## Initiating the e-signing process The e-signing itself can be started through the export button at the top of the document. Instead of pressing *Docx* or *Pdf*, the user can click on the dropdown menu and choose *E-sign*.
If you want to “promote” the use of e-signatures for certain documents, you can also insert a global placeholder *System-defined > Export buttons > Promote E-sign Export Button* and set its value to true. The result will be that the e-signing button then gets “promoted” to the top bar, instead of being part of the dropdown menu.
# Introduction to concepts What are concepts, why are they so important, and which elements of data do they store? {% embed url="" %} ## What are concepts? Concepts are central to the functioning of Clause9. They have a dual purpose: * They represent **defined terms** in a legal document (typically words that get capitalised in formally drafted contracts, e.g.: “the Employee”, “the Commencement Date”, “Confidential Information”, etc.) * They provide a central **storage location for datafields**. Both purposes will often — but certainly not always — overlap. Hence, a concept should be created *either* because that word would typically be written with a capital, *or* because you need to define a few centralised storage locations related to that concept. Both purposes at the same time will also happen very frequently. For example, a typical employment agreement will almost certainly have to use the concepts `#employer` and `#employee` — not only because both words would typically be written with a capital in formally drafted contracts, but also because various datafields relating to an employer or an employee will be relevant (e.g., an employer’s address, an employee’s function, an employee’s commencement date, etc). ## Breakdown of concept information
When you create a new concept, you are presented with several options to provide information about them (see the column on the right-hand side in the image above). Below, we go over each pane. * **File name** — The pane shown in the screenshot above. It allows you to set the file name of the concept's file, optionally in multiple languages. Similar to the filenames you would use on your Windows pc or Mac, file names should not be too long, to allow users to quickly glance over lists of files. * **Description** — An optional pane that allows you to provide a description for a concept, for example in which kind of documents this concept should be used, or how this Concept is different from another concept. This content can later be searched on. Unlike file names, there is no real limit to the length of the description you can provide. * **Category** — Allows you to group different concepts into common categories. If a document simultaneously refers to many different concepts, it may get difficult to find the concept you are looking for. Grouping into categories can then help. * **Links** — Allows you to link the concept to clauses and other concepts to express relationships. * **Datafields** — Remember the second purpose of a concept in Clause9? This pane will allow you to attach dynamically updated information to a concept (such as names, addresses, company numbers, etc.). * **Concept labels** — This pane relates to the first purpose of concepts in Clause9, which is to provide a tool to show defined terms in a legal document (typically in capitals). Which term will actually be used for a certain concept can be freely defined by the legal user who assembles a document, but in general it is a good idea to provide a small collection of predefined terms for each concept (e.g.: for the concept “contract”, we could provide concept-labels of “contract”, “agreement”, “master services agreement”, “non-disclosure agreement”, “share purchase agreement”, etc.). * **Access rights** — manually determine who the owner of a concept will be (if you want to designate someone other than yourself) who will then have editing rights over this file. You can also determine access rights for everyone except the owner. * **Data expressions** — A "data expression" is an advanced functionality. Its purpose is to avoid having to recreate certain calculations across different clauses and will only be available to legal engineer user profiles. For more information, click [here](/datafields/data-expressions). # Creating concepts Concepts can be created either from within the file browser, or within the Assemble document environment. Assuming you have sufficient rights, you can create concepts by going to the *Browse files* tab, and navigating to a suitable folder where you would like to store the concept. Alternatively, you can create concepts directly from within the *Assemble document* environment*.* ## Using dedicated concept folders It is advisable to create separate, dedicated folders that will only contain concepts. Such dedicated folders will be automatically hidden for non-authors and users of ClauseBuddy, avoiding that such users — who may not be familiar with concepts — would get confused when encountering concepts while browsing for templates or clauses. Folders to hold concepts can most easily be created by clicking on and choosing *Concepts folder*. This will create a dedicated folder (in purple) that will get automatically hidden for beginning users:

A newly created Concepts folder (shown in purple).

You can also convert an existing folder into a dedicated concepts-folder by selecting it, clicking on , and navigating to the *folder* subsection at the right side, and finally changing the *Folder type* to *concepts:*
## Creating a concept within Assemble document Instead of using the file browser, you can also create a new concept directly from within the Assemble document editor, by typing a hashtag followed by the name of your new concept. A popup will then appear, inviting you to create a new concept:
# Concept labels Concept labels are the terms which are used for a certain concept when it is shown in a document preview (such as Assemble Document mode). For example: | **What is written in the clause** | **What is shown in the text** | | ---------------------------------------------------------- | --------------------------------------------------------------------- | | `1. #Distributor shall supply #product inside #territory.` | *11.2 The Distributor shall supply the Product inside the Territory.* | Clauses created in Clause9 are to a large extent reusable thanks to the concept labels assigned to concepts. If we take the previous example again, this is what the preview could also show to allow for reuse of that clause in an entirely different context: | **What is written in the clause** | **What is shown in the text** | | ---------------------------------------------------------- | ------------------------------------------------------------------------------ | | `1. #Distributor shall supply #product inside #territory.` | 11.2 The Supplier shall supply the Services inside the European Economic Area. | In the above example, the concept labels for `#distributor`, `#product` and `#territory` were changed from *distributor*, *product* and *territory* to *supplier*, *services* and *European Economic Area* respectively. ### Managing concept labels Concept labels can be freely defined by the user who assembles a document, but in general it is a good idea to provide a small collection of predefined terms for each concept (e.g.: for the concept “contract”, you could provide the following concept labels: “contract”, “agreement”, “master services agreement”, “non-disclosure agreement”, “share purchase agreement”, etc.). Concept labels are created by either predetermining them under the concept label tab of the concept editor or by assigning them ad hoc in the context of a specific document using the terms pane of the Assemble Document mode. When filling out a concept label, regardless of whether you do this in the concept editor or in the terms pane of Assemble Document mode, you can provide additional information on certain parameters of that concept label. These parameters work as follows: * **Terminology**: under “singular” and “plural”, you can fill out the terms that need to appear if the concept is set to singular or plural respectively. For the concept “tenant”, you can fill out “tenant” as the singular version of the term. ClauseBase will automatically fill out the plural version of the word if it recognises it. * **Gender**: you can set references to the concept (e.g.: “he”, “she”, “it”) to be automatically conjugated thanks to Clause9’s intelligent language support. This means that Clause9 can assist you in automatically changing, for example, “he” to “she” or “his” to “her” when switching from a concept label with a male noun to one with a female noun. Clause9 also supports grammatical conjugation based on noun gender for languages where this is relevant, like French and will automatically fill out the gender of a concept label if it recognises it. * **Article**: here you can decide the article that should normally appear before the term if no specific article is hardcoded in the Clause9 grammar. By default, this is set to a defined article (“the”), as this is most common. * **Default singular/plural**: sets the default way in which this concept label is shown. Usually you will want singular but for some labels, like “Services” or “Parties”, you can use this to automatically be set to plural. * **Capitalisation**: determines how capitalisation of concept labels is portrayed. This is particularly useful for concept labels consisting of multiple words. * *adapt to grammar and styling*: follows the predetermined styling set for definitions and how their corresponding terms are displayed. * *adapt to grammar only*: follows (only) the capitalisation used in writing the concept label in the Clause9 grammar, i.e.: `#supplier` will always result in “supplier”, `#Supplier` will result in “Supplier” and `#SUPPLIER` will result in “SUPPLIER”. The predetermined styling set for definitions will be ignored. * *fixed*: sets capitalisation exactly as you filled it out under the “terminology” part of the concept label and will always be shown this way, regardless of document styling settings. A typical use case are brand names, e.g. `#clausebase` or `#Clausebase` should always result in “ClauseBase” regardless of the capitalisation used in the concept label itself. {% hint style="danger" %} The setting “adapt to grammar only” should only be used in very limited cases as this setting means the concept label will ignore styling settings everywhere. {% endhint %} {% hint style="success" %} If you have a need to use a specific type of capitalisation of a concept label in a particular spots, you can always make use of the special functions `@lowercase`, `@uppercase`, `@capitalize` and `@capitalize-words`. {% endhint %} {% hint style="info" %} Note that, instead of defining the singular and plural form of a Concept, it may sometimes be necessary to define two different concepts (one for the singular, and one for the plural). {% endhint %} ### Possessive form In English, the possessive term of a concept label is written by adding an *apostrophe + s* for singular words or *s + apostrophe* for plural words. There is no need to code this manually in Clause9. Adding *apostrophe + s* at the end of the relevant concept will make sure Clause9 will output the correct possessive form of the concept label. E.g. `#borrower's` will become *the Borrower's* if the concept is set to singular and will become *the Borrowers'* if the concept is set to plural. The same technique will also work for Dutch (i.e. adding *apostrophe +s)*, if slightly different in output due to the difference in grammatical rules. --- [Next Page](/llms-full.txt/1)