Clauses - FAQ
Last updated
Last updated
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).
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.
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.
Insert the clause into your document.
Select it and click the pencil icon, then click “convert to independent ad hoc clause”.
Add the you want to the “” property of the ad hoc clause.
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.
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.
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.
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.
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.
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:
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.
