Overview of Records Management in SharePoint Server 2010

By: Matt Morse | Posted: October 19, 2009 at 8:42 AM Add Comment | Share It | Category: SharePoint Server

Note: The contents of this post are based on the SharePoint Server 2010 technical preview, and are subject to change without notice. Microsoft has invested in a number of areas in SharePoint Server 2010, and many of those investments are aimed at making SharePoint an even more serious contender in the ECM space. This post will be an overview of the new records management capabilities of SP2010; I will follow this with a detailed treatment of a number of the areas that are mentioned below.

A Brief Look Back

Microsoft introduced records management with MOSS 2007, and the functionality is generally fine. There is a basic but powerful routing mechanism for classification of incoming records based on content type. The mechanism for handling record metadata works well. The interface to the record center is exposed as an easy-to-use web service, and the API provides a number of straightforward hooks for extensibility (e.g. the ability to create a custom record router). Finally, the ability to put documents on a hold (or multiple holds) and have those documents exempted from any expiration or destruction policies works well. However, the features are critically limited in a few significant areas. First, in its default configuration, a SharePoint farm supports a connection to only one record center which, depending on data volume, can be a significant scalability problem. In addition, documents submitted to a record center make a copy of the source docum ent; the user doesnt have the option of removing the document from the source location. Finally, the options for declaration of a record are limited; a user can choose to manually send a document to a record center, and its possible to send records using custom workflows, but theres not a way to create rules regarding record declarations (e.g. that every Contract stored in a system must automatically be a record). As noted, the record management API works well, and its possible to develop rich solutions on MOSS 2007 that compensate for some of the functionality thats not provided natively. Whats exciting about SharePoint 2010 is that Microsoft has addressed many of these limitations and the out-of-the-box experience for records managers will present a very interesting case for use of the new platform. And now on to the new features!

In-Place Record Declaration

One of the very significant changes in approach for SharePoint RM is the addition of the capability to declare records in-place without moving them to a record center. This is a feature that may be activated at the site collection level. Once activated, the in-place records management feature adds capabilities to the site collection and to document libraries that allow documents to be declared as records.

Once declared a record, a doc is subject to a different set of policies (more on this below), a different set of permissions (e.g. which users may edit/delete documents), and to the standard record hold functionality.

Multiple Connections per Farm

SharePoint 2010 allows farm administrators to define multiple connections to record centers per farm and not simply to define the connections, but to specify more detailed parameters about the behavior of those connections. In addition to the behavior that MOSS supported (which was to define an entry on the Send To menu for a document, then copy that document to the specified record center), SP 2010 provides the ability to move the document to the record center, or to move the document, but leave a link in the original location. Its also possible to define a connection that does not show up on the manual Send To menu but which can be used in automated record submission scenarios. The details of setting up these connections look like this:

Better Integration with Information Management Policies

One thing that stands out about the new features provided by Microsoft for records management is their pervasive nature. While in MOSS records management sort of sat off to the side (with a connection only via the 'Send to menu), in SharePoint 2010, records management functionality can be found sprinkled throughout the product. This is good thinking on the part of Microsoft, as it is reflective of the perspective of records managers at organizations. Solid records management isnt an afterthought: its something that must be incorporated into day -to-day business processes. Perhaps this is seen most clearly in the incorporation of records rules into SharePoints information management policies and specifically the policy around retention (renamed from expiration in MOSS). (Note: the retention policy logic itself has been vastly upgraded in SP 2010. Thats beyond the scope of this specific post, but its worth exploring if youre interested in automa ted retention rules.) We see the change in direction first in that retention policies now allow two separate rule sets one for documents that are not declared as records, and one for documents that are declared records.

The second major integration point with information management policy is that there are now predefined actions related to records management. In the example below, I can configure my policy to automatically submit a document to a record center at a specific time in this case, two years after the Contract Date.

Theres also an action that will declare a document as a record without submitting it to a record center, leveraging the new in-place RM features.

In short, its now possible to merge a record declaration and organization str ategy with the retention and management policies of the front-end systems. Like many of the other items mentioned here, this is functionality that is possible in MOSS only with significant development effort.

Routing Rule Processing in Record Center Sites

There are a number of improvements in the processing of routing rules within record center sites, but I will focus on three here. First, theres now an ability to have a routing rule match on a set of logic, rather than just the document type itself. For example, you might want to send Contracts for a specific vendor to a different location than Contracts for another vendor. The only way to have done this in the past was through the use of separate content types. Now, the routing rule configuration in the record center allows for rules to be evaluated on the metadata of the item being received. In the example below, theres an Amount column on the incoming content type. This rule will only be applied if the value in that column is greater than or equal to 10,000.

A second significant improvement to the routing rule configuration is the ability to route to locations outside of the current record center site. In MOSS, default routing rules can only send documents to libraries within the current site. (You can extend that functionality by creating a custom record router, but that involves some development.) In SP 2010, the destination location may still be a local document library or it may be any other site within the site collection that has a content organizer specified. (More on content organization in a future post.) Note the Browse button in the image below.

The third significant change is the ability to have more control over the folder naming when documents are placed into document libraries. In MOSS, folders are named somewhat randomly based on the date of submission to the record center. This ensures that the number of documents in a given view is kept low, but doesnt provide a logical structure for navigation. In the image above, you can see the option to specify a foldering strategy based on the values provided in the metadata. So in the Contract example, I can choose to have all contracts with the same client end up in the same folder; when a new client contract comes along, a new folder wi th that clients name will be created automatically. This has positive implications not only for visual navigation, but for search relevance, as well.

And theres more

There are many additional detailed features related to records management. I believe I ve hit the highest points here, but there are a number of additional details

Ability to serialize documents by a unique document ID, then find documents by that ID. Ability to declare sets of documents together as a record. (See an introduction to document sets here.) Ability to export a summary file plan spreadsheet from a record center summarizing the rules in place there. Ability to copy documents on a hold to a specific SharePoint location. Ill cover many of these details in future posts.

Summary
Microsoft has invested heavily in Records Management in SharePoint 2010, and organizations who have an investment in SharePoint would do well to evaluate its capabilities. I dont think it will outperform point solutions on a feature-by-feature basis in the RM space, but there is significantly more functionality than was present in the SharePoint 2007 version enough that I think it will meet the standard needs of many companies. After all, one significant benefit of SharePoint is precisely that its not a point solution, but rather a platform that provides a breadth of solutions common to many organizations. It may not be the strongest option in each specific area, but the sum of the options that it provides makes it a great value for small offices and enterprises alike.