Records Management Feature -- "Records Center" sites (Part I)

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:

  • Automatically receiving/routing records declared from other sources: As mentioned in the previous post, declaring records from SharePoint sites is a lightweight process because Records Centers are able to determine how the Content Type of a declared record translates to an appropriate record series in the file plan, and then file the record into the appropriate location. This is the capability that we’re going to talk about in this posting.
  • Hold orders: Of course, one of the primary drivers of Records Management in an organization is to ensure that those records are available in the event of an inquiry or litigation. The Records Center includes a powerful hold order system to locate records relevant to particular event requiring a hold order, suspending disposition of those records for the duration of the event, and for resuming normal disposition once those events have ended. (More about this in our next few posts.)
  • Separate access controls: In the 2007 release SharePoint has improved greatly its ability to control security settings at a very granular level --including security for individual documents or list items-- and to grant users only specific permissions (for example, the ability to add items but not to edit them). This is an especially valuable capability for a Records Center because it gives you the flexibility to specify whether users can access any sections of the Records Center, whether they can view or add items, independent of the permissions those users have on collaborative sites (where they probably have permission to add, edit, and delete work-in-progress items).

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.