Collabware CLM Delayed Record Declaration and Minor Versions in SharePoint

Jayson Kennedy, Apr 16, 2014

A common question we receive from our users is around our Delayed Declaration trigger. Users will upload a document and, knowing that it will be automatically declared a Record by the Delayed trigger, leave it alone. Sometime later, they return to the document and note that it is not yet a record, even though it has fulfilled its delayed period. Surely this must be a bug, they think, and report it as such to Collabware.However, what many of them do not realize is that the document was not declared a record because it was not allowed to become a record yet. This article will examine the Delayed Declaration trigger, and a common misunderstanding associated with it, explain how and why the Delayed Declaration trigger interacts with Minor Versions, and request your feedback on this feature.

Delayed Declaration

First, let’s talk about Delayed Declaration and how it works, for those unfamiliar with the feature. Delayed Declaration is set on a Content Rule when you are associating it with a Policy.

Delayed 1 Delayed 1

The Delay Period can be set to any time frame desired. When an item is uploaded to SharePoint, it gets a “Last Modified” date. Every time it is edited, that Last Modified date is updated. If the item is left alone, not modified for the Delay Period, then it will automatically be declared a record. Of course, all of this assumes that the document in question has fulfilled the Content Rule – if it hasn’t fulfilled the Content Rule, it has no Record Category or Policy to be declared to.

Pending Pending

The screenshot above is the Record Details of a document that has fulfilled the Content Rule for our Delayed Policy. There are two important fields highlighted. The first, Record State shows that the Rule has been fulfilled: the “Potential” Record State means that this document has satisfied a Content Rule, but it has not yet been declared a Record. In essence, it could be a record, but it is not yet a record. The Potential Record State is not limited to Delayed Declaration; all documents become Potential before they are declared a Record.

The second highlighted field shows any special status the item may have. In this case, it has the status of “Pending Record Declaration”. This indicates that the Content Rule is waiting a Delay Period before it will automatically declare the item a Record. Note that it does not show how long the Delayed Period is; there is no warning before a Record will be automatically captured by the Delayed Declaration.

Minor Versions in SharePoint

Occasionally, people will run into the following issue: they have set up a Delayed Declaration rule, and they are expecting it to become a Record, but it does not. They have set up the Rule properly, as shown above, so what could be wrong?

The first answer, always our first suggestion when a user reports this behaviour, is that the Record Collection Timer Job has not yet run. This Timer Job is responsible for declaring all documents that have fulfilled their Delayed Period. It is set to run nightly. As always, we advise users to wait a day, then check. If it still has not been declared a Record, that means that Record Collection has actively skipped it. But why would Record Collection skip it?

In this situation, what we normally find is that the library they have the document in is set to allow both Major and Minor Versions of SharePoint documents, and the document in question is a Minor Version. This is, of course, the reason why Record Collection skipped the document.

To explain why Record Collection skips Minor Versions, let's walk through a short example of how Minor Versions work in libraries.

Versioning Versioning

Minor Versions, as shown above, are meant to represent drafts. Now, this is an important point to consider. With Collabware CLM, anything that is not yet a Record is also considered a "draft", by virtue of not being finalized and thus not being a Record. So if an organization decides to use Minor Versions, they are creating "drafts of drafts". Along with this, there are extra visibility concerns around Minor Versions, as the example below demonstrates.

Minor 1 Minor 1

As you can see, we have a Minor Version document that was created by the Administrator account. Depending on the settings of the library, other users may not be able to even see that the document exists. Let's log in as another user.

Nothing Nothing

In some cases, Minor Versions are limited to only those who can edit the draft, effectively locking out those users who only have the View permission. In other, stricter cases, the draft is only viewable by the Author and those who are responsible for Approving the document. While this setting is something that can be customized, we have found that this approach is favoured by many larger organizations where security is an important concern.

In the end, this feature also leads to the reason why Minor Versions cannot be declared Records. If a Minor Version has a chance of not being visible to all users, then it should not be captured as a record. The concern is around inadvertently locking users out of seeing a Record permanently; if the document is rendered Immutable, then it cannot be edited any further. It would be stuck as a Minor Version, and invisible to a set of users.

Since we cannot check to determine whether or not all users can actually see Minor Versions, we decided that Record Collection will simply ignore the Minor Versions when doing a Delayed Declaration. This is a conscious decision that was made by Collabware when building the Delayed Declaration feature.

Business Cases - We Want to Hear From You

Hopefully this article has helped explain why Minor Versions are not being automatically declared by the Delayed feature. In the end, Collabware has leaned towards caution when it comes to capturing records without input from the user.

Currently, Collabware advises all customers that if they wish to use the Delayed Declaration feature, they are recommended not to use Minor Versions, as there are too many chances of documents not being properly declared. And vice versa, if the organization wishes to use Minor Versions, they are advised not to use the Delayed Declaration feature, for the same reasons. Part of this is a training issue, as simple education could prevent users from forgetting to publish a document as a full Major Version. However, as it stands, your organization may wish to choose one or the other. Minor Version is a useful tool for keeping unfinished content private, while Delayed Declaration is a great catch-all to ensure that documents are being captured as records even if users forget to manually declare them.

However, we are a company that prides itself on being able to respond to the business needs of our clients. As such, we are now asking for you to respond to this article. We have explained our reasoning around blocking Minor Version Delayed Declaration. Now we are opening the discussion to request business cases that would support automated declaration of Minor Versions. If you have any comments or questions regarding this article, please e-mail