Following on from my first post, this article continues to explore the potential limitations of using SharePoint 2010 to meet enterprise compliance and governance demands. This time I'm focussing on in-place RM.
Microsoft have made a huge effort in SharePoint 2010 to enable you to do records management within collaborative spaces. Auditing, Retention, Expiration, Reporting, Records Workflows, eDiscovery, Legal Hold and Recordization are all features you can use in a collaborative space to attempt to strike a balance between SharePoint’s value to end users and the need for information governance.
Holding all of this together is a new feature in SharePoint 2010 called In-Place Records Management. This allows specific SharePoint documents (or blogs, wikis, web pages, and list items) to be declared as records.
The system can prevent such records from being deleted or edited, if necessary, by your organization’s definition of what a record is:
This recordization process can be done either manually, as part of a larger process in a workflow, or as a scheduled part of a document’s retention (e.g. after 2 years). The key here is that, when declared a record, the content doesn't move to an archive – it stays where it is so the end users can still find and interact with the content.
Once declared, the system knows about an item’s record status, so you can do things such as create different retention policies for records or use record state when defining workflows in SharePoint Designer. Microsoft also enables a programmability model so you can perform custom processes and policies upon recordization to meet specialized compliance needs.
Now, this is a positive idea, managing content in-place makes sense to me. Providing governance and record-keeping for information shouldn't necessarily mean you remove it from its original context or that it isn't still actively useful, and therefore in some cases it should remain within the collaborative space. However, I think the implementation of in-place RM is a somewhat knee-jerk reaction, and it doesn't stand up to any serious practical use.
This isn't intended to be damning, but just consider the following limitations before deciding in-place records is the answer to all your SharePoint RM woes:
- Declared items cannot be sent to the Records Center manually, this results in an unfriendly error message. This goes against described methodology, where you might declare a record in-place, but then move it to the Records Center after 2 years. This makes it difficult to implement a hybrid system. Note – It may still be possible to send to the Records Center through policy, I am testing this scenario
- Declared documents can be saved as a new copy of the original record. However, this appears to break things, a new document is saved in the library, it is already declared as a record, has the same unique ID as the original (Ouch!) and yet shows the edit menu options (However, any attempts to edit result in errors). Clicking on the unique ID for either document always opens the original. However, I may have just hit on a bug here
- You cannot declare a Document Set as a record, results in a error. You have to view the contents of the Document Set and then declare all documents inside it
- Declaring in-place potentially leaves the content in the collaboration site for a long period of time, unless another defined policy moves it to a Records Center
- Almost impossible to enforce a corporate file plan, as in-place records will most likely be scattered around site structure. This means organizations may have to resort to basing policy on content types rather than folder/site structure. However this potentially means hundreds of content types that need creating and managing in order to deliver the required RM granularity
- Difficult to monitor and manage the content and policies due to documents being stored across different sites
- Hard to tell which non-document items have been declared as records, items are not ‘padlocked’ like document libraries. See the following tasks and calendar examples, both have a number of items declared as a record within the list
- Non-electronic document items still have ‘Edit Item’ enabled after declaring as a record. Attempting to edit any properties results in an unfriendly error message which doesn't explain the item has been declared as a record
- There doesn't seem to be any visible site column denoting Record Status. The system can identify which information is a record, but as a user I cannot create filtered views or searches just to show me records or non-records. There is probably a way to achieve this, but certainly not using out-of-the-box site columns
So, in summary – In-Place Records Management is certainly a good idea, to an extent. But in my opinion, it just hasn't been implemented fully enough to make it a viable solution. In fact there is no way to leverage a corporate hierarchical file plan together with keeping information in context. A hybrid approach could be considered, but this doesn't seem to be properly supported, and probably would make governance and record-keeping even more complicated and difficult to understand. Bear in mind I haven't deployed any of this functionality in the field, so therefore I'd be interested in hearing any concrete experiences of real-world usage.