February 8, 2009

SharePoint Records Management 101: Creating Site Columns

Posted by Don Lueders under Fundementals | Tags: , , |
Leave a Comment 

chalkboard-site-columns1As I discussed in an earlier SRM 101 post, you should create all your required Site Columns before putting your Content Types together.  (Obviously, given the evolving nature of any organization’s metadata requirements, you will almost certainly have to come back and create new Site Columns and alter your Content Types.)

 
To create a Site Column, login as someone with Administrator privileges and click on Site Actions > Site Settings > Modify All Site Settings.
01 

Under the Galleries column, select ‘Site columns’.  (Duh.)

02

In the Site Column Gallery, click on ‘Create’.
 03

For the new Site Column, enter the column’s name and select the type of information in the column.
 041

To simplify managing all your columns, it is a good idea to bunch them into groups.  Either select an existing group or create a new one.

05
Next, you can enter a brief description of the column, determine if the column is mandatory or optional, limit the column’s length and create a default value.  
 061

Click ‘OK’ and you will return to the Site Column Gallery where you will see your newly created column.

 07

That’s it.  Now your new Site Column will be available for use in your Content Types.

 

September 30, 2008

Event Based Records Retention in SharePoint – Part 3

Posted by Don Lueders under Methodology | Tags: |
Leave a Comment 

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.

 

September 26, 2008

Event Based Records Retention in SharePoint – Part 2

Posted by Don Lueders under Methodology | Tags: , |
[2] Comments 

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.

 

September 25, 2008

Event Based Records Retention in SharePoint – Part 1

Posted by Don Lueders under Methodology | Tags: , |
Leave a Comment 

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.