"I do declare, Frank Kennedy! You look dashing with those new whiskers.…" is a phrase we heard from Scarlett in Gone with the Wind.According to the Merriam-Webster dictionary, to Declare is:
1 : to make known formally, officially, or explicitly
2: to make evident : show
3: to state emphatically : affirm
In our records management world, we declare records. The other day, someone asked me about declaring records and why we have to do that. Some organizations say that in the age of information governance, 'everything is a record' so there should be no need to declare something a record, while others say a record is just the stuff with business value/evidence of what the organization does, in which case, often a person has to make that decision (please forgive my over simplifications of the 'what is a record' definition, but that is a whole other discussion). Anyway, it got me thinking.
In physical records management, we effectively declare something a record by picking up some paper, looking at it and putting it in the 'keep' box instead of the 'shredder' box. A decision is made, primarily because to keep all paper would take a lot of space, cost a lot of money and be impossible to locate at a later date. So to keep things manageable, we identify those items that have business value etc. and declare them as records (by effectively putting them in a box, indexing and labelling the box so we can find it again, and adding a 'keep until' date on the box – keeping boxes forever can be expensive).
Now the digital world comes along and this concept is carried over. SharePoint, and many other records management solutions, need the user to 'declare' content a record. The software needs to know when something is done, made official. So we have this declare button users can press to make something 'done' (aka complete, final, finished etc.) and we can lock it down - preserve it so you can't modify it or delete it. And in the case of SharePoint OOTB, we can start the clock ticking on its retention period.
The funny thing is that before working in the records management field, I had no idea what declare meant. All I knew was that I was 'done' with something and 'done' was different depending on what I was working on. A contract expired, meeting minutes were issued, a deliverable was signed off, a change control was approved. I kept things as evidence of what went on for anyone who came after me, and also to CYA in case anything went sideways. And in my projects based world, it was only when the project finished that I wanted to package up all the project stuff and put it away in case I needed it again. If I was still around in 5 years, and the box was still in my office, I would destroy it.
During all this, not once did I think I was declaring a record. In fact, I was inadvertently declaring records, but as an end user I was doing this with the business language of the content I worked with.
So, back to my colleague's original question, "Why do I have to declare a record?"
The answer is, with the right tools, you shouldn't have to, but it does take a little up front planning.
Firstly, let’s separate the idea of locking something down - preserving the content and preventing deletion - from triggering the start of a retention period.
You have to figure out when things are considered 'done'. Is it a date when something completes, or is it when a status changes to final, or is it some other criteria? For example:
- board meeting minutes might have an issue date
- an employee performance review might have an approved date
- a contract might have a status of 'Executed'
- a document might have a status of 'Final'
In SharePoint, these might be custom metadata column values on their respective content types. With the right tool, you can define your 'done' rules based on the content types and metadata and behind the scenes, you can lock down the record when that condition is true. We would still need to use SharePoint's 'declare' to preserve the content, but it would all be done behind the scenes. So, no, end users do not need to declare records and do not need to know what declare is.
Mind you, it does take some work to figure this out for all your content. Some organizations choose to implement content rules for well understood content areas, but still have the manual declare option for others. In that case, users will be trained to press that declare button when the content is 'done' and needs to be locked down.
Now let's look at what triggers the start of the retention period.
Sometimes the retention clock starts once a thing is 'done'. So we can use the same content type and metadata values to trigger the disposition clock. Other retention policies are based on some event. I might have a record, but I don't want to the clock to start ticking on its retention until some future event. This could be a date when a record is found to have no further business value - made obsolete, or has been superseded by something else - or some other event has occurred.
Project completed, employment terminated, matter closed, equipment decommissioned; these are all 'case file' based events - things that usually have a start and an end date. During the time that a the case file is open, records are created inside the case file and considered 'done' but typically the clock does not start ticking on its retention period until the case is closed.
So back to the question of declare, "As an end user, why do I have to declare a record?"
With the right tools and configuration, you don't have to. SharePoint still needs it under the covers, but from an end user perspective, you don't need that step.
Collabware CLM can put the declare step under the covers, where it belongs, and by implementing appropriate business metadata on your SharePoint content using Collabware CLM content rules to automate the declaration and retention policy triggers, your end users can have that simple, seamless and transparent end user experience that will increase your user adoption and compliance without them even knowing.
As for all that ‘not done’ stuff and potential records, check out my previous post ‘The value of a Convenience File Policy’.
While I was putting this post together, I also ran across some interesting related discussions in the AIIM blog: