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 document; the user doesn’t 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 it’s possible to send records using custom workflows, but there’s 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 it’s possible to develop rich solutions on MOSS 2007 that compensate for some of the functionality that’s not provided natively. What’s 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. It’s 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 isn’t an afterthought: it’s something that must be incorporated into day-to-day business processes.
Perhaps this is seen most clearly in the incorporation of records rules into SharePoint’s 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. That’s beyond the scope of this specific post, but it’s worth exploring if you’re interested in automated 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 pre-defined 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.
There’s 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, it’s now possible to merge a record declaration and organization strategy 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, there’s 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 anoth
er 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, there’s 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 doesn’t 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 with that client’s name will be created automatically. This has positive implications not only for visual navigation, but for search relevance, as well.
And there’s 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.
I’ll cover many of these details in future posts.
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 don’t 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 it’s 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.