SharePointRecordsManagement.com

In MOSS 07 documents were routed to the Records Center and classified in the file plan based on the document’s Content Type.  This worked fine if retention and disposition of your records was managed purely by the type of document being declared. 

As Records Managers, we know this is rarely the case in the real world.  A human resources department, for instance, would create a number of very different document types, all of which would be declared into the file plan folder for the employee to whom the records applied.   This might include Offer Letters, Employee Evaluations, Awards, Disciplinary Actions, etc.  All of these records would be maintained in the employee’s personnel folder throughout the employee’s career and retention would not begin until the date the employee left the organization. 

For these types of records, simply classifying based on Content Type (e.g. ‘Employee Evaluation’) proved painfully inadequate.  To manage the record properly, one or more pieces of additional information – in the form of metadata – had to be leveraged to ensure correct classification.  An Employee Evaluation record can’t be managed for retention and disposition effectively – but an Employee Evaluation for Employee Number 321654 can. 

To solve this problem, Microsoft introduced the Content Organizer in SharePoint 2010.  Unlike the MOSS 07 Records Router, the Content Organizer routes documents based on their Content Type and one or more of the document’s properties.  I believe this new feature will be a tremendous leap forward in improving the ease and accuracy of the SharePoint records declaration experience.

Here’s how you setup the Content Organizer:

First, the Content Organizer must be activated on your site.  To do this, go to Site Actions > Site Settings and click on ‘Manage Site Features’ under ‘Site Actions’.

Click on the ‘Activate’ button to enable the Content Organizer.

 Once the Content Organizer has been activated, two new options will become available under ‘Site Administration’:  ’Content Organizer Settings’ and ‘Content Organizer Rules’. 

In upcoming posts, I’ll explain how you use ‘Content Organizer Settings’ to configure a number of useful Content Organizer options and I’ll explain how to use ‘Content Organizer Rules’ to set up rules that allow you to direct documents to specific parts of your file plan based on Content Type and metadata values.

In one of the more perplexing acquisitions I’ve seen in the Records and Information Management industry, Autonomy recently announced it was acquiring CA Technologies’ Information Governance division.  (Here’s industry analyst, Forrester’s early take on the deal.)  This means that Autonomy will now own – along with a few secondary applications – CA’s Records Manager solution.

My sense is this was a strategic decision by Autonomy to acquire a proven DoD 5015.2 certified records management application.  The confusing part is that Autonomy already owns (also through acquisition) both Meridio and Interwoven. 

Having worked with all three of these products (particularly Meridio), I can tell you they all provide some excellent records and information management functionality.  The problem, though, is there is a great deal of overlap between the features these solutions provide.  Additionally, my personal experiences haven’t given me any confidence that Autonomy fully understands the records management space, so I’m afraid this deal may be taking CA’s solution out of the hands of a few very qualified Records Management professionals and dropping it into an organization that that doesn’t know exactly how to leverage its capabilities. 

So what is my advice if you are currently using any of these solutions?  At the very least, wait to see how this acquisition plays out before you renew any agreements.  Autonomy has a lot of work ahead of it if they plan to integrate all of these products into one unified solution. 

Having said that, this may very well be a good opportunity to repurpose the money you have allocated for CA Records Manager, Meridio or Interwoven into a new SharePoint deployment or a SharePoint 2010 upgrade.   

Just a thought…

[This is the first installment of an occasional series of posts on this subject.]

From the start, one of the primary goals of this blog has been to provide Records Managers with a better understanding of some of the critical technical issues they are likely to encounter while managing their records in a SharePoint environment.  And while I don’t expect readers to fully understand everything about any technical issues I write about (frankly, I don’t fully understand some of them myself), I do hope that I’ve provided enough information on some issues to give you fundamental understanding of how things work and how it applies to SharePoint-based records management. 

Which brings us to cloud computing.  The notion of cloud computing is certainly not specific to SharePoint nor is it specific to records management.  But it is relevant to SharePoint records management because it is an absolute paradigm shift in how information is managed and your organization will almost certainly consider moving some or even all, of their Information Technology services to a cloud-based solution.  And this includes your records repository and the solution you use to manage it.

So just what, exactly, is Cloud Computing, then?  Good question.  If you asked a hundred IT guys to define cloud computing, you are very likely to get a hundred different answers.  (And worse, I once asked a sales guy from a cloud hosting service what it is and he told me, ‘It’s whatever you want it to be’.  Thanks for the help, bud.)  I like to stick to a fairly simple definition.  To me, cloud computing is nothing more than Internet-based computing where an organization shares resources (hardware, software, technical support, etc.) delivered through data centers physically separate from the organization. 

Normally, customers don’t own the cloud computing infrastructure they use.  Instead, they essentially rent it.  There are two basic pricing models for cloud computing: a subscription based model and a utility based model.  The subscription based model requires a set payment for using the hosting service’s infrastructure and typically minimizes the restrictions it applies to the customer’s usage.  The utility based model packages the hosting company’s resources into a metered service whereby the customer pays only for the resources they use, just like they pay for their gas or electricity. 

To be clear, cloud computing offers tremendous benefits for managing your SharePoint deployment, but it also poses some potentially disastrous risks.  In the next installment of this series, I’ll explain what they are.

Early last year when I created my SharePoint 2010 Records Management Wishlist, one of the first items I included on the list was a unique and persistent records identifier.  MOSS 07 used a document’s URL as its identifier, but this proved not only unwieldy (it was typically an enormous string of incomprehensible characters), it was also impractical because the URL changed whenever the document’s location changed. 

A unique and persistent identifier was possibly the most glaringly obvious omission from the MOSS 07 ECM/RM infrastructure.  One that had Records Managers all over the world scratching their heads wondering whether Microsoft really had a complete grasp of document and records management fundamentals. 

Well, good news!  Apparently Microsoft was listening to me.  (OK, more likely me and about a million other MOSS 07 users – but I won’t nitpick.)  SharePoint 2010 includes a Document ID Service that allows you to create a unique identifier that travels with your document from creation to final disposition without ever changing.   

The Document ID service creates a ‘Document ID’ column in the SharePoint 2010 Document Content Type.  The Document ID column is available in any document Library throughout the site collection.  In addition, the Document ID service allows you to specify a set of 4-12 characters that will be used at the beginning of the identifier.  This prefix can be used to ensure that records from different site collections will never be assigned the same Document ID.

When configured, this is what a Document ID looks like:

Here’s how you setup Document IDs in SharePoint 2010:

Go to Site Actions and select ‘Site Settings’.

Under Site Collection Administration, select ‘Site collection features’.

Click on ‘Activate’ to enable the Document ID Service.

Return to Site Collection Administration and you should see a new option, ‘Document ID settings’. 

Click on ‘Document ID settings’ and check the option to ‘Assign Document IDs’.  This is where you can also add the optional 4 – 12 character ID prefix.  You can also set the search scope for the ID.  (As this is likely to be a critical field, it’s probably a good idea to set this value to ‘All Sites’.)

The process of assigning Document IDs is managed by a timer job, which means documents aren’t assigned IDs immediately.  So don’t expect to see Document IDs as soon as you create the document. 

Also, if you have documents that existed prior to enabling the Document ID service, you will have to check them out and back in again before they are assigned IDs.