SharePoint 2010 Records Management Overview
Guest Author: Michal Pisarek
Before we dive in to creating our Records Management solution its worth to overview the various tools and features that we will use to construct our solution. SharePoint 2010 has come leaps and bounds in Enterprise Content Management, a vast range of these tools can be applied to our Records Management solution as well.
In forming a solution it is worth to try to determine what we are trying to accomplish. In essence Records Management refers to the practice of maintaining the records of an organization from the time they are created up to their eventual disposal. This may include classifying, storing, securing, and destruction (or in some cases, archival preservation) of records (thank you WikiPedia!)
But in essence we want to achieve the following:
- A way to construct content that will become records
- A way to classify records
- A way to store and secure records
- A way to report on records
- what are the tools that we can use to accomplish this?
Constructing Content
Constructing content in the SharePoint sense is the definition, creation and upkeep of Content Types. The great thing about using SharePoint as a Records Management platform is that all content can be managed from a central location.
SharePoint 2010 however adds two vital features that aid in the creating of Content Types:
Content Type Syndication (CTS)
This to me is the unsung hero of the SharePoint 2010 platform. CTS allow us to define and manage the lifecycle of Content Types in one central location, with the ability to publish Content Types across Site Collections, Web Application and even Farms. This was a huge issue in MOSS 2007 as updating Content Types across Site Collections was problematic at best.
Now we can define our Content Types, with metadata, templates and in our Records Management mind set Information Management Policies, from one location and control those Content Types effectively.
Managed metadata
Just as CTS allowed us to centrally managed Content Types, the Managed Metadata Service provides the ability to centrally define metadata attached to Content Types. This gives us the ability to easily control the metadata that is so vital in order not to construct but also to classify and report on records.
Managed metadata also offers huge advantages in terms of the interface it presents to users. It makes entering metadata easier, and the more information that users add to their content, the better it can be classified and managed within a Records Management Scenario.
Classifying
Information Management Policies with Multi-stage Retention
This is one of the many improvements in SharePoint 2010 that is specific to Records Management. The ability to define retention schedules that have predefined triggers and associated actions closely models how many of the big players in the Records Management space work.
In essence it will allow us to control content as it moves from stage to stage in our retention plan, and with the addition of CTS we can neatly wrap these retention policies up in our Content Types and distribute them across the entire farm.
Default Metadata
Interestingly this is one of the new features of the platform that hasn’t got much attention, but I love it. You can now define default metadata at the document library level for any column that is present. In Records Management I really like this because we can route content to a folder and then automatically add pre-defined metadata to it simply because it landed in that location.
It makes things easier and more consistent, helping us to classify our content a little more effectively.
Unique document Identifiers
One of the more highly touted features in the ECM toolkit of SharePoint 2010 is the concept of unique document identifiers. This will give us 2 major advantages in creating a Records Management solution. Firstly we can now associated a unique identifier to a piece of content and retain that identifier across the entire lifecycle of the document. This means we can be confident that the content has not been altered or tampered in any way.
More important however is the easy findability of the document, regardless of its location within SharePoint. A unique document identifier does not contain the location of the document when you are trying to retrieve it so a user can find a document regardless of whether it has moved to the Records Center or is anywhere else within the system.
Compliance Information
Compliance information is now easily viewable from the context menu of any piece of content stored within SharePoint 2010. The more exposure that users have to routing policies, seeing if an item is a Record or other information such as Holds really help users understand the various policies that are attached to the content that they are using.
In Place Records Management
Another new ability is to mix Records and Non Records within the same library. This is a really cool feature that does make it much easier to get users to use the records management features inside of SharePoint since its now part of the user interface.
Now there is some tradeoffs to this approach and it is mainly to do with the fact that it is difficult to create complex routing rules using inplace records.
Multiple Send To Locations
With MOSS 2007 only one send to location could be defined. Now with SharePoint 2010 you have a whole host of options that can be leveraged in a Records Management scenario including new options when an item is sent, multiple locations to send to and the ability to actually hide send to location from users to distinguish items that have been moved manually and items that have been moved as part of a policy.
Store and Secure
Hierarchal File Plans
Another of the big feature changes for Records Management within SharePoint 2010 is the ability to create a hierarchal file plan. This relates to defining different disposition policies within different folders within our file plan.
The way that this is implemented within SharePoint 2010 is through the new ability to be able to specify the Information Management Policy source for content. We can now choose to override the disposition policies attached to a Content Type and use the policy defined in the folder.
Hierarchal file plans are a huge deal for Records Managers everywhere as it gives them the control to specify retention details down to a very granular level.
Records Centers
We also have a new Records Center template available that contains a number of useful features such as a in built Content Organizer, a search box where users can search for content by document identifier, a default Records Library to store records and an improved administrator interface.
Content Routing
The Content Organizer is the feature that will link our Content Types complete with metadata to our file plan. We will use the Content Organizer feature to organize documents within our file plan where they can then take on the retention rules defined on the folder that they belong in.
Reporting
Electronic Discovery and Holds
The eDiscovery aspects of the platform have also been greatly enhanced. Now we can search for content and create legal holds to track actions such as litigations, investigations or audits when we need to suspend any alterations to content.
Although not strictly part of creating a Records Management solution, it is a vital part of the capabilities that SharePoint offers
Metadata Driven Navigation
Again tied with more with the ECM capabilities of the platform but vital in a Records Management scenario. Essentially if we have many documents in a records center we need some way to be able to navigate those documents, and it shouldn’t need to be via the file plan.
Metadata driven navigation gives us this capability, allowing us to quickly navigate even through the largest of file plans with ease!
So as you can see a lot of the new ECM aspects of the platform we will use to create our Records Management solution. Really what we are doing is not creating a Records Management solution but a small ECM solution that emphasizes the Records Management aspects of SharePoint. But that is one of the great features of the platform that we can use pieces of functionality on so many different levels to craft the solution that we need.
Stay tuned for the next installment when we start to define our Content Types and metadata using Content Type Syndication and the new Managed Metadata Service!
Guest Author: Michal Pisarek
Michal Pisarek is a solution specialist for Habañero Consulting Group, a Microsoft Gold Partner in beautiful Vancouver Canada. He has been working with SharePoint for 3 years and has a passion for finding the right balance between technology, innovation, governance and fun to meet his client’s needs.
You can find other articles by Michal on his blog SharePointAnalystHQ or follow him on Twitter (@michalpisarek)
- Create a Records Management Solution in SharePoint 2010
- SharePoint 2010 Records Management Overview
Hi Makie,
Glad you got Part 2 published!
Your post is a great, concise but complete overview of the new Records Management features provided with SP2010.
As far as the Managed Metadata, I was trying to use it as a cascaded dropdown of sort but it didn’t work out as I would have hoped. When taging content with a ’sublevel’ tag, is there a way to display not only this tag but also the parent, grand parent etc.,..?
Greg
Hey Greg,
You can display the tag and subtag in the actual field if when you create your managed metadata column there is an option called Display Format.
If you set this to ‘Display the entire path to the term in the field’ you should get this to show what you like.
I have this option set but it seems to work in reverse for me.
term: supplier > product > sub type
if i start typing supplier i just see supplier and not the full path, typing product shows nothing…
Hey Shaz,
That is strange..the only thing that I can think of is to make sure that all of the terms that you create in your Term Set, regardless of which level they are at, are available for tagging.
Otherwise I don’t really know what the issue could be since it works for me….
Hi Michal,
I am stumped on how to send – using content organising rules – files to a document set.
It *seems* that you are restricted to folders only.
Also, when creating a new folder using content organising rules, SP includes a prefix – how can I either get rid of it or customise it?
Greg
Hey Greg,
You actually can route to a document set, even though it looks like you can’t because when you click on the browse destination button only folders will appear.
To do this you need to put in the URL of the Doc Set in the Destination field. So for instance if your records library is at http://spahq/Records/RecordsLibrary and your Document Set is name ‘Document Set One’ you would specify ‘http://spahq/Records/RecordsLibrary/Document Set One’ as the URL and it will route to it.
The reason is that a Document Set is actually a folder with some trickery thrown in but this works, try it otherwise I will blog about it soon.
In terms of the prefix you have the option of either having the property name or the unique property or a combination of the two selected. I’m sure this can be changed through code but I haven’t had a look into it.
Michal,
thanks for your prompt response.
Is there a way OOTB (or not) to use some metadata fields (LU or managed metadata) to route the documents to a doc set specific to this fields?
For my current application, I will have 1 doc set per project (keyed EP-01, EP-02, EP-03, … which belongs to a projects list). Reason why I have a doc set rather than a folder is that you can download a zip copy of the doc set (which is part of the deliverables for those projects – you need to be able to download and burn on a CD all ‘final’ documents we gathered and produced and this on a project basis)
I was hoping that I could select which project the doc in the drop of library relates to (via a drop down looking up to my projects list) and use
my key (EP-01 etc….) as a parameter in the URL Path: …/Library/DocSet{parameter equals to the value selected in the drop down for the project key, EP-01, EP-02…., RGV-01, RGV-02, etc…}
I do not see this available OOTB but I may be mistaken (please tell me so, it would make my day!)
Thanks again for sharing your knowledge!
Greg
Michal,
I’ve been working with the Content Organizer and ran into an interesting problem. At first I thought the CO was useless… but have since found a solution that I’d like to hear what you have to say.
I was using a lookup list as my property for target location. Basically if the job number is entered then use the value of the job number property as the target location.
However it was not working… every time I tested it, the CO created a new folder with a unique prefix (like Greg mentioned above.) Even if the folder or doc set existed it would create a new folder with a 3 digit prefix.
For example… if my project number was 10001.01 it would create a folder with a 3 digit prefix 585;1001.01. Next project would say 586;1002.01, then 587;1003.01, etc… all the while I already have the projects created as doc sets… just 1001.01, 1002.01, 1003.01, etc… but it would ignore them and create the new folders.
Interestingly enough… if I chose the 1001.01 project a second time… it would not create a second 1001.01 w/ a new prefix, but it would place the second document in the 585;1001.01 folder. So it does recognize existing folders… but only the folder it created with the prefix.
After a day of pulling my hair out… Finally I changed the property to a text string and it worked as advertised. It routed it exactly like it should… worked great for a metadata term set as well.
So the conclusion is that we cannot use a lookup list value as a target location in the content organizer.
So I was wondering if you’ve seen this or possibly have an explanation. I’d really like to use a lookup list. W/ what we are doing with the different lists we’ve found the LU list is much easier to manage than a term set in our environment.
Maybe you can test it to see if I did something wrong.
Thx.
Jason
Another informative article. Anything you want to write about on IA, record/document management in SP2010, I am anxious to soak it up. Thanks!
HI ,
Can Records Management •Content Organizer be used to move items in a list library to a different list library in the same site?
Unfortunately out of the box the Content Organizer only supports document content types so you can route list items with it at all.
Hi, great article to bring a new user up to speed on RM.
My question is as follows: We have a business team that creates monthly sales actuals reports (a content type). Each instance of the report must be managed as a seperate record (so the January report is a different document from the February report etc) so that their destruction dates can be seperately managed (ie Jan report is destroyed before the Feb report etc).
The business users want to be able to:
a) create a link once off that always points to the “latest” copy of the report, and have it automatically open the most recent report instance for use on a web page displaying other information. (can’t use doc ID as Doc ID is different for each instance.)
b) easily identify and group all instances of that type of report
c) preferrably manage records in-place
Can you provide some suggestions on how best to use content types / folders / document set / content organiser rules or something else to meet the above please.
Hi Liz,
Thanks for the comment, sorry for the late reply.
There are a number of ways that you can approach this so let me take a stab since some option will satisfy some requirements and other option will satisfy others!
In terms of creating a link to the latest version that isnt really possible without some development effort. But what is possible and easy would be to create a view that will show the latest version only for example, but the URL will be different. I assume you want the URL to be consistent so you can send out an email link and have users click on that and open up the document, rather than looking in SharePoint.
Now for the Records Management part this is interesting! Since it seems like you want the reports destroyed before creating others you might be able to do the following:
a) Create a content type called Report with all your metadata that you need
b) Create a column called ‘destruction date’ which will be a calculated column of the last day of the month of the report (pretty easy to do)
c) On the Content Type define an Information Management Policy which states that when the Destruction Date is reached that the report will be declared a record (make sure that you have In-Place RM enabled for the library)
So with this approach you know that at the end of the month your reports will automatically become records in the same location and can then have various retention policies applied.
To easily identify and group all instances of the report you can create views or use metadata driven navigation. One tip would be to create a view called ‘Archived Reports’ and create a filter where the IsRecord field = true, this will give you all your Reports which are currently records.
Let me know if this is any help or if I am on the right track
Cheers
Michal,
I just discovered this excellent post and found it quite helpful.
I am interested in your thoughts on how to define a metadata field under the following circumstances:
* The metadata field needs to be validated against a set of predetermined valid values.
* We want certain end users to be able to add to the list of valid values for the field.
* The content type is to be managed as a business record.
* We will need to route it to a record center.
We could use managed metadata, but if we’re going to syndicate the content type for use in the record center, I believe that means that the only people who could add a new “valid value” for the field would be those with access to the content type hub.
We could use a “choice” field type, but again, it seems that users would have to access the content type hub to add a new valid value.
We could use a lookup field, validated against a list, with the list living in the same site collection. List entries cannot be declared as records themselves, meaning someone could remove or change an existing “valid value” from the list, or change a description field in the list stating what that list entry means.
What approach do you prefer when a business record needs a validated metada field to which users can add choices?
Thanks again for the excellent tutorial post!
Regards,
Tim