Hi. I have a schedule to an agreement that sets out the form of a separate document (eg Schedule 1 - Consultancy Agreement Template). The separate document is a separate template and I’d like the version appearing in Schedule 1 to automatically adopt any changes made to the separate template. Is this possible - like if I add or delete a clause in the separate template those same changes will be made in the version appearing as Schedule 1 to the other document.
I realise that any changes I make to clauses included in both documents will appear in both, but if clauses are added or deleted from the master I wouldn’t think they’d be added/deleted in the schedule, yes? That’s why I’m wondering about linking from the schedule to the actual document so all changes in the document also appear in the schedule. I hope that makes sense…
I’m not completely sure this will answer your question, but I think that what you want to achieve, is indeed the default behaviour of ClauseBase.
-
Any changes made to the contents of library clauses will always be reflected in all the documents that make use of that library clause. It does not matter how you make this change.
-
You can include any independent document X as a “subdocument” S1, S2, S3, … in any number of Binders.
When you then:
- would change the contents of a library clause that is used in X/S1/S2/S3, it will be automatically changed in X, S1, S2 and S3 — irrespective of whether you make that change from within X, S1, S2 or S3. This flows from paragraph 1. above;
- would change the “structure” of X (i.e., which clauses are inserted, in what order), those changes in the structure will be automatically reflected in S1/S2/S3, EXCEPT when S1/S2/S3 would have been “unlocked”;
- conversely, when you would change the structure of S1 — e.g. insert an additional clause in S1, or remove a clause from S1, or indent a paragraph in S1 —, neither X/S2/S3 would reflect that change;
- similarly, when you would change the structure of S2, this would also not affect X/S1/S3;
- similarly, when you would change the structure of S3, this would also not affect X/S1/S2.
In other words: another instance of a document will follow all the changes in the structure of their original document as long as that other instance is not unlocked.
The underlying idea is that, usually, when you insert a subdocument in a Binder, you will want it to automatically adopt all the changes made to its original document, so that you do not end up in the typical situation in MS Word, where you actually don’t know whether a schedule (subdocument) is still exactly the same as the original schedule.
However, there are sometimes situations where you want to deviate from this standard behaviour — and for those situations, you can click on the unlock symbol. Once you unlock, the link with the structure of the original document is removed, so that the two structures become separated.
You will want to read this document: (Un)locked documents in a binder – Help
Thanks Maarten. That all makes sense, however what if a schedule in the binder is a form of the separate document? For instance, ifa consultancy agreement includes a schedule that sets out the form of a an NDA that the client requires the consultant to use whenever engaging a subcontractor, then Schedule 1 would show a title of:
SCHEDULE 1
Form of Subcontractor NDA
Non-Disclosure Agreement
But the actual NDA template would have a title of
Non-Disclosure Agreement
The content of the form of Non-Disclosure Agreement is the same, except that in the schedule the additional heading texts “SCHEDULE 1” and “Form of Subcontractor NDA” appear at the top in the master agreement binder instance.
Ah, I now see what you intended to ask.
You have several options:
-
You can copy/paste the clauses from the NDA template in the Schedule 1. All library clauses in it would still pick up any changes, but the structure of the NDA template would then not be synchronized between the two.
-
You can create a “clause hierarchy” — essentially a packaged combination of clauses — that you would then insert into both the NDA template and the Schedule 1. You can think about that clause hierarchy as a kind of “mini subdocument”: it is also “locked” to ensure thhat changes in the structure will be syncrhonized unless unlocked.
I guess you will want to use this second path if there are multiple differences between the NDA template and Schedule 1 — e.g., both in the title section and in the bottom (signature) section, which is typically missing in a Schedule, but will probably be present in your standalone template.
- If the only difference between the NDA Template and the Schedule 1 is the title & subtitle, then I would actually
- disable the document’s title
- insert a new clause that then contains the title and/or subtitle, and subject it to a simple condition (like
#nda^show-title), and assign it custom styling “Format as document title”
Thanks Maarten, the hierarchy approach is definitely what I’m after because it avoids the possibility of someone modifying a document template example in a schedule when the actual template hasn’t been modified or vice versa. I noticed that after I unlocked a test hierarchy I was able to add clauses to it but I couldn’t lock it again. I assume that’s because the additional functionality mentioned in the article you linked to hasn’t been implemented yet. When do you think editable separate hierarchies will be available?
The inability to lock again is deliberate — it is not something omitted / waiting to be implemented. It’s actually quite sophisticated how it works, so let me explain:
If you insert a hierarchy of clauses or subdocument (they actually work the same), ClauseBase essentially stores a pointer (illustrated in red) to that hierarchy/subdocument file:
When ClauseBase opens the Binder, it will also fetch the original documents A and B, and copy/paste their structure into the Binder as subdocuments A and B:
As long as the hierarchy/subdocument remains locked, the software can easily pick up any change in the structure of the original hierarchy/subdocument file, even after you closed documents and later on reopen them. After all, it’s just a pointer and the software will simply copy/paste the then-current structure when you reopen the Binder, no matter how many changes you made to the structure.
Once you unlock the hierarchy/subdocument, things change drastically. Instead of having a simple pointer to ##100011 in the Binder, ClauseBase will have to store pointers to all the different clauses of the unlocked subdocument. For example, if we unlock subdocument A, ClauseBase will store three pointers to the different clauses
In fact, after unlocking subdocument A, the Binder will simply no longer store a pointer to the original document #100011, but will instead internally store a copy of document #100011. That document copy and the original #100011 will from that point live a separate life, even though they may themselves point to common clauses.
The software is actually quite smart, and tries to limit the amount of copies it has to make. (The idea being that you try to preserve the structure as much as possible.)
For example, in the illustration above, you will note that only a single pointer is used for clause 102 (i.e. the Binder does not store pointers to subclauses 103 and 104). As long as you do not change the structure of clause 102 from within the Binder, that clause 102 will be implicitly locked, and all structure-changes you would make to clause 102 (e.g., if you would insert a subclause 999 below subclause 104) will be picked by the Binder upon reopening — or any other document or binder that would have a pointer to clause 102. After all, when opening the Binder, the software simply picks up the then-current version of clause 102, and pastes the structure into the subdocument.
Conversely, if you would insert a subclause 999 to subclause 104 from within the Binder, then the structure of the instance of clause 102 within the Binder will get destroyed, so that future changes to the structure of clause 102 will no longer picked up by that Binder. (Other documents or binders that would point to clause 102 would, however, still pick up the changes.) Technically, ClauseBase will then store a copy of clause 102 in its copy of subdocument A.
No matter how many levels deep you would go, the software will always try to point to the original document/clause as much as possible.
When reading this technical explanation, I hope you now understand why it’s not possible to afterwards lock again. (The reason being that, once unlocked, a copy of the original subdocument is stored instead of a pointer to that subdocument.)
We are fully aware of the fact that this all seems complicated. However, the alternative (which virtually all other software packages use) is to either always make copies of everything — i.e., simple copy/paste like MS Word would do — or to not allow make internal changes to embedded files (and if you would want to make changes, an integral copy will be made). ClauseBase deliberately takes a more sophisticated approach, by trying to preserve as much of the content as possible, and only making copies when truly necessary.
Also, important to note, is that all of this of course only relates to the structure of subdocuments and clauses. Changes to the body / title / etc. of library clauses will always be reflected, no matter which unlocking happens and copies are being made.
Thanks Maarten for the detailed explanation. Is it possible to set user permissions so they can fill in Q&As but not unlock subdocuments in a binder? That might answer my concern in conjunction with your suggestion about hiding the document title.
There are indeed user permissions (configurable by the administrator of each customer) to enable/disable the right to unlock clause hierarchies and subdocuments.
1 Like
Yay! You guys have thought of everything! 