SharePoint 2010 Records Management | Decoupling Retention Schedule from Content Types
There are very few solutions that have more of an impact on the business than Records Management. Records Management involves the identification, management, and disposition of business records. Proper management of these assets is essential to manage compliance and litigation risks. If mismanaged, it could cost an organization millions if not billions of dollars. SharePoint has become more of a standard for information workers within the enterprise to manage documents. As such, it is also looked to as the first consideration when managing documents that are then identified as records.
In previous versions of SharePoint, this was a challenge because the tool quite frankly just wasn’t mature enough to handle enterprise-level records management. One primary concern was that SharePoint 2007 required records be managed in a centralized repository which required records to be separate from the working library. SharePoint 2010 addresses this issue with the concept of in-place records management. With the In-Place model, records are defined where they currently live and are side-by-side other working documents. This is accomplished by applying document retention at the content type level. The great benefit of this model is that it provides the necessary context for the record to tell the whole story.
With all of the benefits that the In-Place model provides, it does introduce one business or role gap. Because the retention schedule is defined at the content type level, a site collection administrator must manage retention as part of their overall taxonomy strategy. In practice, however, it is the Records Manager who will be tasked with defining and maintaining the retention schedule. In most cases, the Records Manager will not be a site collection administrator and thus would have to coordinate with the admin to make any changes to the retention schedule. It is this role gap that needs to be addressed with any Records Management project a fellow consultant encounters.
I encountered such a project recently where we had to address that very issue. To compound the matter, this client had no document classification structure in place to speak of so utilizing any content type based retention schedule was simply not possible. To solve all of these problems, we created a custom solution that de-coupled the retention schedule from the content type structure. By providing a single, centralized SharePoint list that represented the retention schedule, we were able to give the Records Manager access to manage this list. Then, with the help of some custom prompt screens, we were able to gather all of the information that we needed depending on what type of record the end user declared. Given that information, we were able to define a single "Record" content type used for all records.
The end result of all of this work was a system where the Records Manager had full control over the retention schedule and out of the box disposition facilities were used to manage the record expiration.
Although this is not an article intended to describe a particular solution, it is an example of what considerations need to be taken into account in understanding how Records Managers work and how to architect a design within SharePoint 2010 that will truly meet their needs. By applying this mindset, SharePoint 2010 can now truly be an enterprise-ready Records Management system.