Now that we’ve covered how records are declared from collaboration SharePoint sites, in this post we’re going to start exploring the “Records Center” site template provided in Microsoft Office SharePoint Server 2007 for collecting & managing records in an organization.
What is a “Records Center” site?
A “Records Center” site can be thought of as a “Records Management Application” in the traditional sense. While other SharePoint sites are generally optimized to maximize end-users productivity, Records Centers are primarily for use by Records Managers. The structure of the site can be organized to match your file plan (rather than how end-users might want to organize content), the policies for content in the site can be configured to match your retention schedules, and the metadata for that content can be set up to capture whatever information you need for the long-term management of those records. (It really is your site. :) )
Because it’s based on the same technology foundation as the other sites in Office SharePoint Server 2007, all of the features we’ve discussed in this blog are available in Records Center sites. And the Records Center also has some additional capabilities to make it a great Records Management Application.
What are the additional/unique capabilities of a Records Center site?
There are several capabilities unique to Records Center sites in the 2007 release. These are:
How does a “Records Center” site receive records declared from SharePoint?
As mentioned in our last post, the burden on end-users when declaring records is minimal – the Records Center site does the work of inferring where that record belongs in the file plan, based on its Content Type. This inference is accomplished in the Records Center using a special list called the “Record Routing” list. This list stores a the set of rules that specify how the Content Types of records in collaborative spaces map to record series in the Record Center’s file plan. It is the tool by which a Records Manager can define these mappings once, rather than require end-users to specify for each record at declaration time where in the file plan it belongs.
A (simple) example Records Center site, showing the "Records Routing" list
Each rule can specify one or more Content Type names that identify records belonging to a particular series, a description, and the location where records with a Content Type matching that rule will be filed. This ability to have multiple names is a subtle but critical capability – it allows a Records Manager to specify that even if different regions or departments have different Content Type names for their respective collaborative spaces, those names all represent the same type of record in the file plan and should be filed together.
Additionally, one routing rule can be marked as the “default” – this is the location to which records will be routed whose Content Type name doesn’t match any other rule.
The following image shows the user experience for configuring a routing rule for a “Supplier Contracts” record series. The rule specifies that any declared record whose Content Type is “Supplier Contracts”, “Agreement”, or “Contract” should be filed in the “Supplier Contracts” document library in the Records Center. (It also shows a field that I haven’t mentioned yet… more on that in a later post.)
Configuring a routing entry for a Records Center site
So the first step for the Records Center in receiving a declared record is to match the name of the Content Type of the declared record to the appropriate rule in the routing list (which may be the “default” rule if necessary). Once the correct location has been determined, the Records Center will check to see if the metadata attached to the record before it was declared matches the metadata required for that location in the Records Center. Any metadata that matches will be used to populate the corresponding fields in the Records Center.
If the existing metadata is enough to fill in all required Record Center fields, then the record will be routed to the specified location, and the declaration process is complete. If additional metadata is required, then the record will be temporary kept in a special “holding zone” to which the user will be directed to fill in that metadata before the record is routed to the specified location.
In addition to storing the record itself, the Records Center will also store all of the record’s metadata and audit history from the collaborative space as separate files in the specified location. So in the event of any dispute over the authenticity/accuracy of that record, even long after it was declared, the original information about the record from its collaborative life is still available.
Hopefully this post helps explain how the 2007 release of the Office SharePoint system helps greatly reduce some of the pain generally associated with end-user record declaration & classification.
In our next posts we’ll continue looking at the capabilities of Records Center sites, including how they can be configured to allow end-users to manually file records if desired, how the routing of declared records can be extended to perform functions like de-duplication and routing based on metadata other than Content Types, and of course hold orders.
Thanks for reading!
- Ethan Gur-esh, Program Manager.