Thanks to ClauseBase’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 ClauseBase.
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.
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).
Your administrator may have disabled this button. By default, it is only visible for advanced user accounts.
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”.
ClauseBase 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 Documents, 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.
It is probably a good idea to move old versions to a separate folder, e.g. called “archived versions”.