Hello from the Microsoft SharePoint Conference 2011 in Anaheim CA.
Many enterprises use Microsoft SharePoint for Records Management. Despite how much has been written on this, Records Management is sometimes confused with Document or Content Management , but it’s in fact quite a unique discipline with its own best practices and processes. Microsoft SharePoint 2010 provides some great features to enable these processes, and it provides enterprises with the appropriate controls over the data and documents that they declare to be corporate records. Here at the Microsoft SharePoint Conference, Records Management figures pretty prominently among several of the sessions. There’s lots to learn here about managing records and I’m going to review some of that in this post.
Introduction to Records
To start things off, a record refers to a document or some other piece of data in an enterprise (electronic or physical) that provides evidence of a transaction or activity taking place, or some corporate decision that was made. A record requires that it be retained by the organization for some period of time. This is often a legal or regulatory compliance requirement. As well, a record by definition must be immutable, which means that once a document or piece of data is declared to be a record, it must remain unchanged.
These requirements for records immediately suggest certain processes that must be in place to ensure that they’re managed appropriately from several perspectives: business , auditing/legal , tax, revenue , and even business continuity. As we often find, for business processes to be applied consistently across all SharePoint content or records, automation is a key requirement, as well as making appropriate use of metadata.
Working with Records in Microsoft SharePoint
Declaring Records and Retention
First, its important to determine what type of content should be considered a record. For example, if I’m working on my department’s budget for next year, my initial draft and its various iterations should likely not be considered records because they are still changing – they are not yet approved, nor are they final, nor can I make any decisions based on those preliminary versions. But once my budget is ‘approved’ or considered ‘final’ then it can be declared a record because I can now base corporate decisions on it. Establishing a policy around what type of data is a record requires planning, meeting with appropriate stakeholders and agreeing on policy that’s communicated to everyone that may be declaring content as a record.
Next, its important to assign a retention period to records. The period for which records are retained, along with the process followed once that time period has expired, is a critical requirement for records management. There are legal and business implications to consider when content is kept content too long. The business policy could be that after X years, a record is archived and then after Y years from that point it is disposed (which could include deletion or moving it to offline long-term storage). Again, establishing this policy requires planning and getting agreement from stakeholders, especially around any legal, regulatory compliance, revenue or tax implications.
Records Management Features
Once that policy is in place, Microsoft SharePoint provides several features to enable users and/or automated processes to actually declare content to be a record:
1. Records Center Site
The records center site is essentially a SharePoint site dedicated to centrally storing and managing records. SharePoint 2010 still has the Record Center Site template from MOSS2007, but it now provides integration with several new very useful features including:
- A dashboard view at the site level for Records Managers with searching capabilities
- Integration with the Content Organizer for routing records within the site
- Document ID service to assign a unique identifier to documents which travels with it
- Email Integration with the Content Organizer
- Legal Holds
- Metadata Navigation/Filtering
Depending on the business need, it may make sense to centralize records management and storage in this way. If the business demands that a small number users be considered ‘Record Managers’ and its their role alone to declare content as records then it may make sense to follow this approach and make use of the Record Center Site.
2. In-Place Records Management
This feature allows individual users to declare documents/content as records while they reside in their current location. In using this feature, records do not need to be moved or added to a central Record Center site, nor do they need to be routed within the Record Center. This is a trend in the records management space, because it allows users to continue find content where it resides, based on its business nature or properties.
In-place records management is not enabled by default, and you need to activate the feature at the Site Collection level. You can also configure various options like:
- Restrictions imposed on in-place records: Block Delete, Block Delete and Editing
- Availability of In-Place Records Declaration – if this feature is turn on, then Declare Record and Undeclare Record buttons appear in the ribbon bar for end users; if turned off, then records can still be declared in place but only by workflows or retention policies
- Declaration Roles – specifies the types of users that can declare and undeclare records; the options here are: all list contributors and administrators (any users with the edit items permission), only list administrators, only policy actions (only policies or custom code running as System Account can declare/undeclare records)
Once configured, it will be available for all sites and libraries throughout the site collection. You can then restrict access to it on individual libraries and lists by configuring their settings in Library/List Settings.
The other great features mentioned for the Record Center Site are also available for In-Place Records management.
This type of in-place records declaration and the settings mentioned suggests that other individuals be enabled to make the decisions about declaring and undeclaring records. Depending on the business need, enabling a broader range of end users to declare content as records may or may not make sense. You tend to find that individual employees, those not typically designated as records managers, can be nervous or apprehensive about declaring content to be records for the enterprise because it implies a level of official accountability or legal declaration over that content. So, there are some ways to make this simpler using some automated retention policies and metadata.
3. Retention Policies and Workflows
Retention Policies and Workflows in SharePoint can be used to automatically declare documents as records after a certain time period or based on certain metadata values.
Retention Policy
A retention policy can be configured so that certain actions are taken on documents after a certain period of time. For example, a Retention Policy could be configured so that if a document has not been modified for 2 years it can then automatically be declared a record and moved to the Record Center Site. Retention policies can also be multi-staged so that, for example:
- After a document has not been modified for a year then all previous versions of the document are deleted
- After a document has not been modified for 2 years then it is declared a record
- After it has been a record for 7 years it is automatically disposed
Retention policies can even be configured for non-records (active documents) and used to delete or dispose of outdated or expired content after certain periods of time. In the same site or library you can have different policies for records than for non-records.
Retention Policies can be configured for a number of different circumstances:
- For content types and applied to all instances in the site collection
- For content types at the site level and applied to all instances in the site
- For individual libraries, lists or folders
There is some very good instructions found here on how to configure these policies: http://office.microsoft.com/en-us/sharepoint-server-help/create-and-apply-information-management-policies-HA101631505.aspx
Workflows
Workflows are a very useful and widely used feature of SharePoint. They are used to enable many different business processes across thousands of SharePoint deployments. Some great things you can do when creating a workflow are:
- Configure it to send a document or item to another site
- Configure it with conditions so that it is triggered only when certain metadata fields are equal to specified values
- Configure it with additional actions like emailing users
By combining this condition with these actions, you can create workflows that will automatically trigger when a Status metadata column is set to ‘Final’ by an end user. This can then cause the workflow to automatically send the document to the Records Center Site (causing it to become a record) and send an email to the Records Manager to approve the declaration of the record. In addition, this and other workflows (that perhaps don’t involve metadata) could be triggered by a Retention Policy so that these actions automatically occur after a certain amount of time has passed.
What you accomplish with this type of configuration is that you’ve removed the need and any apprehension for end users to officially declare records. You’ve also used metadata to determine when active documents are ready to automatically become records. You’ve sent a notification to the Records Manager so that they are aware and can provide any approval if needed. And finally, you’ve dealt with abandoned items where metadata is not updated but the document can still become a record if needed.
Due in part to the rate at which content is growing in SharePoint, its easy to see why using automation to declare and manage records is a recommended strategy for consistently applying policies across your farm.
Security Implications
There are some security implications that you need to think about if you are taking sensitive content in SharePoint and declaring it as a record. For example, if you are using the Record Center Site and a sensitive document with very specific item level permissions is declared a record it may be automatically moved to the Record Center, however its permissions will not be moved with it. It will inherit permissions from the destination library within the Record Center. This can be especially problematic if you have a very active Record Center which users refer to often
TITUS Metadata Security for SharePoint can automatically apply permissions to sensitive content in SharePoint, even within the Records Center Site. It can ensure that specific item-level permissions are maintained on content when it is active, and after it has been declared a record. It does this by using metadata to determine the security permissions that must be applied – the same metadata that can be used to trigger records management policies.
With In-Place Records Management, SharePoint can display a lock icon beside a document once it is declared a record. This is a great feature which lets users know that they’re looking at or working with a record. However, if the document is saved locally, emailed or used in other circumstances it can be difficult for end users to realize that they are working with an official corporate record. Its important to ensure that end users are aware of when they’re dealing with official records.
TITUS Document Policy Manager for SharePoint can automatically apply visual labels to Microsoft Office and PDF documents in order to raise awareness about when end-users are dealing with official corporate records. These labels take the form of headers, footers and watermarks within the document, so they travel with the record. As well, they are completely configurable and make use of document metadata, so they can be formatted to conform to corporate document templates. Finally, they can include security labels, information about the retention policy for the record and include disclaimers about how the record can be distributed.
To Sum Up…
Microsoft SharePoint can be used as a full-featured robust Records Management system. It contains some great features that can be used to define the appropriate records and retention policies for the business. Its key to use automation and leverage metadata to ensure that records management policies are applied consistently across all your SharePoint content.
Its also important to understand the security implications and ensure that records, like all sensitive content in SharePoint, have the appropriate permissions and the appropriate visual labels. TITUS Security Suite for SharePoint can help automate these processes , so that end users only access the records they are permitted to access, and so that they understands what is a record and how to handle it.
-Antonio
Comments