SharePointRecordsManagement.com

In previous posts, I’ve discussed two ways you can manage event based retention in SharePoint: customization and the DoD 5015.2 Resource Kit.  In this post, I’ll explain the third option: SharePoint Case Management. 

A lot of my colleagues will say I am significantly oversimplifying things, but for demonstration purposes, I like to divide content into two groups, documents and records.  Documents are essentially any piece of information existing in an organization.  Documents are transitory and can change over time.   For regulatory, historical and business purposes, a small portion of an organization’s collection of documents are required to become records.  This means there is a declaration process where the document changes state, becomes immutable and is assigned a retention period. 

So, an organization has documents and it has records, but legally speaking all of it is evidence.  The courts don’t care whether the results of a discovery order were managed in a records repository or found sitting on a shared drive somewhere.  Legally, it’s all same.

OK, fine, but how does this relate to SharePoint and event driven retention schedules?  Good question.  What this means is that even though SharePoint Expiration Policy is time driven by default, SharePoint and the Records Center can still be used to manage your Case Management (i.e. event driven) records collections. 

To illustrate, we will use the Personnel records example from a previous post.  As you may recall, we assumed your organization had a retention period of ‘Destroy 5 Years After Date of Termination’ for all Personnel records and we had an employee, Joe Smith, who had been with your organization for 25 years.  Previously I suggested that during Joe’s time with the organization his Personnel documents would be declared records over time on a continuous basis.

My suggestion here is that Joe’s Personnel documents are allowed to remain in their original Document Library throughout the course of his time with your organization.  Then, when he leaves the company, systematically, as part of your organization’s Employee Termination Procedure, move all his documents over into a corresponding Library in the Records Center.  This Library would have a standard 5-year Expiration Policy set to the day the records were declared, but that would be fine because the records were declared on the day the event (Joe’s termination) occurred. 

Unless you are in an extremely regulated industry, managing these records in this manner should be perfectly compliant with your organization’s records management requirements, because at no time is any of this evidence unavailable for discovery.

If you are considering implementing a MOSS Records Management solution, I thought it might help to suggest a number of features in SharePoint you should be familiar with.   You don’t need to fully understand the technology behind these features, but understanding how they fit into SharePoint will be a tremendous help to you when you discuss implementation with your IT team or any potential consultants you may need to hire. 

Here is a list of features I think you should understand.  It is in no particular order.  Any good SharePoint technical manual should give you enough information to get a basic understanding of these features.  There is also a lot of free stuff out on the Net that you may find useful, as well.

• Records Center Site Templates
• Records Center Libraries
• Content Types
• Information Management Policy
• Expiration Policy
• Records Routing Tables
• Records Uploads
• ‘Send To Records Center’ Option
• Records Audit File
• Record Properties File

If you can’t find sufficient information on any of these features, drop me a line and I’ll try to explain them and their use in better detail.

Just to be clear, SharePoint is not an application, it is a platform.  Essentially, that means given the right developers you can make it do whatever you want it to.  And just because out-of-the-box Expiration Policy is based on record declaration date does not mean that can’t be changed with a little custom development work.

Here’s how you use customization to configure event based retention in SharePoint. 

Let’s start with an example.  Say you are managing Personnel records and retention assigned to them is ‘Destroy 5 Years After Date of Termination’.  Termination of employment is the event that triggers the start of the retention period.  You have an employee, Joe Smith, who has been with your organization for 25 years.  He has accumulated hundreds of Personnel records over the course of his employment.  You manage these records in a Records Center Library called ‘Smith, Joseph – Personnel Records‘. 

Obviously, subject based retention can not be applied to the records in this Library.  The five year retention does not start until Joe leaves the organization – and you don’t know when that will be.  The custom solution to this problem is quite simple.  Include an attribute in the record’s Content Type (we will discuss Content Types in future posts) called ‘Cutoff Date’.  Keep this field blank as long as Joe stays with your organization.  Have your developers create custom code that bases retention on this new date field.  (This type of functionality has been written by developers before and may already be available on the public domain.)  Set Expiration Policy on Joe’s Personnel records Library for five years from the Cutoff Date. 

Throughout his career with your organization, any new records declared into the ‘Smith, Joseph – Personnel Records’  Library will not have a Cutoff Date assigned.  On Joe’s last day with the organization, set Cutoff Date on all the records in the Library to that day.  (Ideally, this becomes an automated sub-process in your organization’s Employee Termination Procedure workflow.)  Configured in this manner, five years from the date of Joe’s termination all of his Personnel records will qualify for destruction.

Fundamentally, SharePoint records retention (referred to as ‘Expiration Policy’) is time-based (or ‘subject’ based) retention.  This is because out-of-the-box Expiration Policy can only be set based on when the record was first declared.  (OK, technically speaking you can also base expiration on ‘Last Modified Date’, but as we all know, you never modify a record.) 

Subject based retention works fine for most of your records retention schedules, but how do you configure SharePoint to manage your event-based (or ‘case’ based) retention?  Well, as much as I hate to say it, that depends.  There are really three ways to make case based retention work in SharePoint.  They are:

• Implement the DoD 5015.2 Resource Kit
• Create custom expiration policy based on metadata
• Use out-of-the-box functionality in a case management manner

The solution you select will depend largely on your particular requirements.  You may be in a highly regulated industry that requires that your Records Management solution is 5015.2 certified.  If that is the case, you may have no choice but to use the Resource Kit.  I will address the Resource Kit in great detail in later posts, so I won’t discuss that approach in this post.

That leaves the second and third options.  I will split discussion of those two approaches between my next few posts, so stay tuned.

Everyone’s heard of the Three L’s of Real Estate: Location, Location, Location.  (Having just sold my house in this lousy market, I can tell you that there’s a lot of truth to that old adage.)  I’d like to propose a similar maxim for Records Management.  Call it the Three A’s of Records Management: Automate, Automate, Automate. 

Automated Records Management significantly reduces a lot of the major problems faced by Records Managers today and can make your life a whole lot easier.  Here’s an example, if a document is automatically declared a record after it is approved for publishing, it is not up to the end user to remember to do it.  Similarly, if that same record is classified in your organization’s file plan programmatically, you can eliminate the fear of user misclassification. 

Automating Records Management is important no matter what solution you are using, SharePoint included.  SharePoint comes with some terrific custom workflow functionality that you can use to create some simple workflows to automate Records Management processes.  I’m nobody’s developer and I’ve actually been able to create some pretty useful stuff completely on my own. 

No matter what your Records Management solution, do what you can to maximize your process automation.