First, a little background

One of the core features of Collabware CLM when it first came out was automating both the classification and declaration of records in SharePoint. This allowed, and actually encouraged organizations to create solutions in the platform that focused more on business outcomes and great user experience, which helped to drive adoption, and in turn, improve compliance.

In practice, this was achieved with Content Rules. For those of you who are new to Collabware, Content Rules are matching rules that find content in SharePoint based on content type and/or metadata and help us classify that content against our file plan.  For example, a simple content rule could be thought of as:

Find all documents where ContentType = “Agreements" and Agreement Status = “Signed”

Content rules are then mapped to record categories in order to classify content in SharePoint against our file plan. Our updated Collabware scenario could be thought of as:

Find all documents where Content Type = "Agreements" and Agreement Status = "Signed"
and then place into the Record Category "2301-Agreements"

As seen below, it was on this association or mapping of the Content Rule to the Record Category that the records manager could select the type of desired declaration behavior (manual, immediate or delayed (after the last edit)) for a given time period:

So our completed scenario, or instructions for Collabware could be thought of as the following:

Find all documents where Content Type = "Agreements" and Agreement Status = "Signed".
and then place into the Record Category "2301-Agreements"
and then two months after the last document modification, declare it to be a record.

This brings up our first major consideration – how long should we wait before declaring a record for the end user? After all, as soon as we declare, we’ll be locking down the document and protecting it from accidental deletion, but we’ll also be preventing end users from working any further on the document. If documents are declared too early, we’ll motivate end users to keep content out of the system, which we want to avoid. On the other hand, If we wait too long before declaring our records, then we’re putting the organization at risk. Since adoption is one of the biggest hurdles for a successful implementation we need to find that sweet spot. That ideal moment to declare the record, such that we’re not stepping on the toes of our end users.

Document lifecycle vs file plan

Before we go deeper into auto-declaration, let’s consider the typical lifecycle of content. First, it’s created (hopefully in SharePoint) and then worked on by one or more end users for a given time period. At some point, it gets declared as a record and, typically, left in place as an active record as long as it's providing value to the business. Once the document is no longer providing much value to the business (but we need to keep it around as a record (semi-active) in order to meet our needs around compliance) we may choose to send it off to a record center for long term storage.

A classical file plan, born in the world of paper records, usually only takes into consideration the Active and Semi-Actives stages. This makes sense in the paper world, but in systems like SharePoint we can optionally capture the document and classify it against the file plan as soon as the document in created (we call these Potential Records in Collabware CLM).

Our file plans are then typically missing this first phase in the lifecycle of the document as illustrated below.

Promoting retention policies to workflows

For those of you who are on Collabware 2016 will be aware of the promotion of retention policies to workflows. When we think about retention policies in Collabware 2.X, we had a simple retention set up like the one seen below. Where each stage defines the location, duration, and action to take at the end of the retention stage.

And when we think about it, this really is a basic kind of workflow that represents a portion of our documents lifecycle. And since our documents are in a digital format and living in a system, we could potentially do other things with them in this workflow, like sending emails, setting security, reclassifying, or conducting periodic reviews. Our retention policies can now be more intelligent, functional and provide a higher ROI for thebusiness:

Adding Auto-Declaration in Collabware 2016

Many people will instinctively consider baking into the workflow the collaboration period itself. After all, the retain action can put in a waiting period that’s based on the last modified date:

This can allow for intuitive workflows that now show the complete lifecycle of content. In a way, in Collabware 2.X the lifecycle of the document was stored in two places – the delay before auto-declaration which was stored in the content rule and the retention stages which were in the policies:

We have one caveat though as retention policies are typically shared across one or more record categories. For example, a popular retention policy like “2Y; 5Y; D;” that stores documents in place for 2 years, then sends to a record center for another 5 years before destroying could be shared by 100’s of records categories in a large file plan. So instead of redefining the retention policy 100’s of times (one for each record category) Collabware allows you to create it once and then share the retention policy across all record categories, saving hours of configuration and ongoing system maintenance.

However, it’s nature of the document itself (which will be correlated to the record category) that likely determines the specifics around auto-declaration and not the retention workflow. For example, signed agreements would likely be declared almost immediately, while project reports could be worked on for months and being that these documents would likely belong to different record categories, but could share the same “2Y; 5Y; D;” retention policy.  This means that our workflow won't work for all the record categories as it is currently configured.

Collabware gives us three options for dealing with this:

Multiple Workflows

You could create an instance of each workflow for each possible auto declaration. so our “2Y; 5Y; D;” policy could be split into three separate workflows:

• “Immediate; 2Y; 5Y; D;”

• “3 Month; 2Y; 5Y; D;”

• “6 Month; 2Y; 5Y; D;”

Multiple Paths in a Workflow

Alternatively, an individual workflow can have multiple paths and special in line content rules can be created in order to push items through the workflow. These content rules could be as simple as:

Find all documents where ContentType = “Agreements" or where ContentType = "Bid Document"

We could then have several paths coming out of an initial retain action that list all of the content types that should move into another retain actions of varying lengths that map to the likely collaborative window required by end users for that content. Below are some screen shots that outline this scenario:

What our workflow ends up looking like:

Content Rules

Collabware also allows you to define auto declaration in Content rules. So while we are separating our document lifecycle between content rules and workflows, we do get maximum reuse of our retention policies. You will likely find that as you take advantage of Collabware CLM 2016’s workflows they will become more and more specific and you will end up with specific workflows that target certain types of content, in which case you can just go ahead and add the collaboration window to the specific workflow. If you're looking to keep things simple and minimize the total number of workflows, then we can do something like the following where we add a condition in the content rule that matches the modified date being over a year ago:

Fine tuning record declaration

When you’re first setting up your auto declaration you’ll want to be a little generous with the collaboration period so as not to declare anything too soon. You can probably get a good idea of what this should be by talking to end users and using better judgement to determine the length collaboration window before we auto declare. You may want to circle back to certain scenarios at some point in the future to see if our auto declaration settings were indeed inline with how people work.

Collabware offers some added value here as you can pull some analytics out of the audit database. In the example below we’re pulling out the longest number of days between creating and editing a document for each library where nothing has been touched for three months giving us a good idea oft he collaboration window required before declaring records within a given library:

With this information we can circle back to our auto-declaration settings and fine-tune our collaboration window to align with how end users are actually leveraging the system. This could either be extending the window to ensure we're not declaring too early or shrinking the window in order to improve compliance.