In a recent call, I expressed a concern about a clause that I am still working on being deployed as soon as I save it. This seemed less than optimal to me.
Reading the help entry on versioning, this appears to be the answer: that a version is not made “active” until " "set as the active version” is selected.
Is this indeed the answer to my concern?
Hi Kenneth,
I’m afraid not — the “active version” setting mainly means that this clause will be the standard one to be found through the search function. As explained somewhere in the help entry you mentioned, versioned clauses will behave mostly like normal (non-versioned) clauses.
What you are facing, is a direct consequence of the central editing approach taken by ClauseBase. Most of the time this will be of great help to you: unlike most other (template-based) solutions, you can make changes in one single place. But the downside is, obviously, that every change you make will be directly made available to everyone, everywhere.
Somewhat of a solution to your concern is the “disable” functionality in the Q&A options. This allows you to temporarily disable a Q&A when you are actively working on it, so that your users do not inadvertently use it during your editing work.
I want to make sure I am understanding.
When I save as a new version, you are saying that this version is pushed out to all existing documents right away. The only consequence of setting as “active” is how it shows up in the library.
Correct?
That is indeed correct.
And to add to that: the “active” or “inactive” state of a clause is only relevant to users who use Assemble Documents. End-users who merely use the Q&A, will never be confronted with the question of whether a clause is the old or the new version — they simply see a clause show up, irrespective of how old or new a certain clause is.
Could I ask what you are particularly worried about? The versioning system is actually quite powerful when combined with the platform’s other functions — e.g., (through conditions and external snippets) you can even automatically switch from the old to the new version at a particular point in time, or for particular customers or types of documents.
When making drastic changes to a clause, I would advise the following workflow:
Addendum:
There is also a possibility to archive an entire Q&A (and its underlying document, and all of its clauses) to a local file you can save on your hard drive. You can then optionally re-upload that local file onto ClauseBase, which creates an entirely separate copy from this entire structure.
This way, if you are really making intensive changes (not just a few clauses), you can leave the old version up as long as you want, create duplicates of everything, and then remove the old versions when you are done.
This is a fairly specialised situation (I would not recommend to use it often), but it is possible. By the way, by default, it is not activated in standard accounts.
Maarten, coming back to this really old thread (over two years old)…
We have now been using Clausebase for a while and I’ve been trying of late to be a little more hands-on, so that I can be more conversant on coding and helpful to Elmer.
I was tweaking a clause and was excited to “rediscover” versioning. However, I soon “rediscovered” that versioning doesn’t work the way we thought it did or the way we think it should. I soon found this thread, and said “Oh, yeah, now I remember.”
Having reread your thread, though, after two years and with significantly more Clausebase experience under our belts, we (I’m going to speak for Elmer here) still don’t understand your issue with setting it up the way we are suggesting.
To recap, here’s the way we think it would be very helpful for versioning to work:
Our suggested way of handling versioning gives authors the ability to:
If you’re not going to do versioning like this, I don’t see what the point is of having it. In its current form, I view it as unusable. (Elmer could not even find a prior version using search or browse, though I imagine it’s got to be findable somehow.)
Right now, when we want to improve a clause, we have two sub-par choices:
In short, we want to preserve the central editing approach of Clausebase, i.e., that all changes to a clause go live everywhere the clause is used, but we also want have an easy, safe process for updates and improvements. The current versioning implementation doesn’t seem to accomplish anything, unless we are misunderstanding.
The versioning system serves a completely different purpose than what you are envisioning here. It is mostly used by customers to keep a “trail” of old versions of clauses for audit/historic purposes. For example, in April 2022 there was the original version, then in September 2022 something changed internally that caused a new version to be drafted, then in January 2023 there’s a third version with yet another change.
The current versioning system nicely serves that purpose, and we have no intention of removing it, because that would impact those customers.
However, what you are suggesting is an interesting idea. Essentially you are suggesting to replace clause A by clause B in a very easy way (and then optionally in the future swap clause B back to clause A, or to clause C, or …). That’s indeed something that would be useful for everyone, we should be able to implement it in the next months.
By the way, we are also thinking of creating a system to take an entire Q&A and “package” it into some kind of “container-file”, sealing the current state of the Q&A together with all the concepts, datafields, etc. This would allow you to have the following workflow:
I cannot give you hard promises on the deadlines for these things (Q&As are enormous “spiderwebs” of hundreds of small items that have to work together), but these sealed Q&As are definitely something that’s coming in the next months.
Maarten, fantastic that you are considering implementing this. However, I’m surprised you’re giving me any credit for it being an “interesting” idea; I’m not a programmer at all, but from having explored GitHub some time ago as a possible way of tracking versions of my templates, requests for changes, etc., my impression is that what I’m suggesting is something like how programmers routinely use tools like GitHub to update code. I.e., they work on a new version of something, test it out, and at some point, it’s accepted for release and the new version of the code replaces the old one. I’m not sure I can take credit for this being an original concept. But you’re the programmer – you tell me!
I like the similar idea with the Q&A. That seems useful. I imagine that @ElmerThoreson would agree, though he can comment for himself.
By the way, in terms of the current system being used to keep a “trail” of old versions, how does that work? If the point of the versioning is simply to tell you that Clause 1 is related to Clause 2 as an earlier “version,” how does one see that? Is that tagged somewhere? How do you review old versions? (As noted in my original message, @ElmerThoreson could not immediately find that. But in order for it to serve the purpose that you allude to, I imagine there has to be some way to search old versions of a clause.)
Hey Maarten and Ken,
I think I have made some progress on understanding the trail. I realized that we can open the clause in “browse files” and click on versioning to find the history. I am not sure if that is in the documentation, but I seem to have missed it. (See screenshot below).
This makes sense because I can find the trail you mentioned by looking at the version information and the initial version still shows up in “browse files.”
However, we have other versioned clauses where the initial version is no longer present and the versioning tab does not show an initial version. (See screenshot below).
Both are examples of versioned clauses. I see that both have version names, but the second does not (a) still have an initial version in our folder and (b) the “Show Other Versions” area does not show that there was an initial version.
Is there a setting when you create a version that was done differently between the two? Is there some other factor in play that I do not understand?
Thanks,
Elmer
Thank you both for your comments!
After some further discussion, we actually want to take Ken’s suggestion a step further, and create a system where you cannot only swap two clauses, but also simultaneously swap many clauses at once.
This should allow you to, for example, silently prepare different content for clause 101, clause 245 and clause 356. When you are done with your preparations, you can them immediately “commit” the swaps for all three clauses at once — e.g. clause 101 gets replaced everywhere by some new clause 987, clause 245 gets replaced by clause 995 and clause 356 gets replaced by clause 1002. Stay tuned!
I don’t know what happened with both clauses (our standard logs don’t go back before March), but I guess that there is a misunderstanding, because technically it appears to me that:
both clauses are versioned
but both clauses are unrelated to each other
(I can see this in the database because there is a different magical number — a so-called “GUID” — assigned to both of them.)
The documentation for the versioning is available on the Help website. Could it be the case that there is a misunderstanding somewhere on how versioned links are created?
It is currently not possible to take two clauses and somehow make them versions of each other; instead, you really have to start from one clause, then initiate the versioning for that clause, and then create a new version of that clause. With that last step, you effectively create a copy of the initial clause, that is linked to the first clause because they have the same magical number under-the-hood.
Finally, perhaps good to point out that the versioning system was primarily designed to create chronological versions of the same clause. (That’s also the reason why you cannot take two clauses and somehow turn them into each other’s versions.)
When I read the labels of your clauses (“not a change Control” and “Change in Control”), and check the contents of your clauses (one being very long, the other one super short), I get the impression that you are using the versioning system for a different purpose: for creating “families” of legally related clauses. You are of course free to do this — we have seen other customers do it as well — but it is not something we would recommend, because who knows what other “chronology”-related we might add in the future.
Maarten, I’m just checking in on this thread. Is the versioning as I suggested it (and as you expressed an inclination to implement) on the roadmap?
Ken
