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.


Comments (21)

  1. Ethan,

    Thanks for the additional information. Is this naming consistent / changed for Beta 2 TR? Right now on Beta 2 I see "records repository" and "document center". I am confused about the differences – specifically what a document center is – can you please clarify?

    Thanks,

    Michael P.

  2. sam_n99 says:

    Thanks again,

    I don’t know if the content type of the document library in "Record Center" should be the same of the docuement library in Sharepoint Document Site, I think its not necessary!!

    If we declare a record from other application by using "Web Service" how we can do that and how this record will matching with Record Routing?

    Is MOSS 2007 has categories or subject headings to classify docuemnts or records?, and Can I attached some documents related to Main document, without using list?

    Thanks,

  3. @tinsheep:

    Michael,
    Thanks for the clarifying question. Our naming has changed between Beta2 & Beta 2 Technical Refresh.

    In Beta2, the site template now called a “Records Center” was named “Records Repository”. Going forward, the name will remain “Records Center”, which is why it was used in this blog. Sorry for any confusion this caused you or any of the other Beta2 users out there.

    As for the “Document Center”: it’s a different site template in the 2007 release optimized towards storing documents, rather than the “team site” temple which is targeted toward for a team to post relevant documents, calendar events, announcements, etc. In a “Document Center” site for example, SharePoint doesn’t automatically create lists for those other types of information.
    The “Document Center” and “Records Center” site templates aren’t directly related, other than the ability to declare records to a Records Center from any SharePoint site (including a Document Center site).

    Hope this helps clarify,
    – Ethan Gur-esh, Program Manager.

  4. @sam_n99:

    Thanks for the questions. I’ve just posted a "Q&A" post that addresses the first two. (http://blogs.msdn.com/recman/archive/2006/09/19/762561.aspx)

    I’m not sure I understand your third question, though. Can you expand on that one a bit?

    Thanks,

    – Ethan Gur-esh, Program Manager.

  5. sam_n99 says:

    Dear Ethan,

    Firstly, Thank you very much for detailed answer you had provide. And Sorry about my poor english. I am Arabic man in fact 🙂

    About Third question, As you know, systems like Hummingbird, or LiveLink has more options to design a relational Metadata (One To Many), I mean a record or document may has field called Subjects (Like Library Management Systems) to cataloging and classifying this document, this field should link to another table to get the subjects from. and this field should be multivalue.

    In fact, so far I found tool like Bussines Data Cataloge (BDC) very usefull. BDC can link to any table in SQL Server and get the value, but when you declare the column that binding with BDC, you have not any choice to make this column multivalue, so its (One To One) relation and we have not a relational metadata 🙁

    I dont know if this blog will talk about BDC or not? but its great to list this great tool to talk about in the future ….

  6. @sam_n99:

    Thanks for the good suggestion about talking about the Business Data Catalogue features on this blog… I’ll definitely follow up with that team to see if there’s already some good content on one of the other Microsoft blogs about the feature that I can point you to, or if not get them to blog about it here.

    As for your particular question about the Business Data Catalog and multi-value columns – let me check with that team and get back to you.

    – Ethan Gur-esh, Program Manager.

  7. @sam_n99:

    Sam,

    (Firstly, sorry for the delayed response. Things are pretty hectic here as we ramp up for the ARMA conference and of course work on finishing the product. 🙂 )

    Generally speaking, the Business Data Catalog feature wasn’t intended for the taxonomy scenario you’re describing… rather, that feature was intended to make it easier for customers to connect their Office SharePoint sites to business data residing in other repositories or applications. (For more information, see http://msdn2.microsoft.com/en-us/library/ms563661.aspx). For that reason, you’re seeing that it’s not an ideal solution for deploying managing a taxonomy or classification system, and that’s why we weren’t planning to talk about the feature on this blog… although it will probably be a topic discussed on the more broadly-focused SharePoint team blog (http://blogs.msdn.com/sharepoint).

    However, one area to look at to help address your taxonomy requirements is the “Site column” & “site content type” capabilities in the 2007 release. Using these features it is possible to define many different types of columns (including multi-valued columns), and to apply them to all content in a site to enable users to classify content.

    Hope this helps, and sorry again for the slow response time.

    – Ethan Gur-esh, Program Manager.

  8. amr_mahmoud says:

    Thanks Ethan for this post.

    We have a little(as i wish) problem with sharepoint records center.

    We created a site collection which contains a document library named Contracts, this document library based on a content type named Contract.

    We also created a records center site, and when we tried to send a file to the records center using the UI it sent successfully to the records center and i can find it in the Unclassified Records document library.

    Until here everything is OK…then we created a document library called Contracts(in the records center site) and added an entry to the record routing list, then tried to send a file with content type Contract to the records center…here we received the following error

    "An Error occurred while sending the file to the Parliament Records Repository Records Center."

    and here is the details of the record routing entry

    Title:Contract

    Description:Contracts and licenses …

    Location:Contracts

    Aliases :

    Default: No

    Also we can send any file to the records center as long as this file does not have a corresponding entry in the record routing list

    note : we are using SharePoint 2007 B2TR with SQL Server 2000

    thanks in advance

    Amr Mahmoud

  9. amr_mahmoud says:

    It was solved by creating a new web application then create a records center site.

    The problem was that i created the records center as a sub site of the collaboration site

    Amr Mahmoud

  10. I’m glad you resolved your issue.  Let us know if you have further questions.

    Thanks.

  11. Greetings, everyone! In this post, we are going to conclude our discussion of e-mail records management

  12. In the first part of this series, I introduced a custom information management policy. In the previous…

  13. peruris says:

    When a document is sent from a document library to OfficialFile.asmx , it is creating a folder  with timestamp. Is there a way to specify  some thing  like   "Document Title – Guid".  And also I see that the actual file in the folder is also suffixed with some  randomly generated string.  

    Foldername as  2007-03-06T08-59-55Z   FileName_QXYLSE

    Is there a way we can manage or control these names and also can we manage how the properties are stored as xml file. Rather can we change the format to a simple Excel  or CSV format.

  14. peruris says:

    If we have custom properties like customer number, project # stored in the properties folder xml file. How can we configure the search to search these specifi properties.

    E.g.  While discovery process , we would like to search all the documents related to a project # or customer in the record repository

  15. TheKid.me.uk says:

    This is the third post in a series of posts about the Records Center in MOSS. ( Part One , Part Two

  16. In the first part of this series , I introduced a custom information management policy. In the previous

  17. For those folks attending the MOSS and ECM class I delivered in Boston/Waltham, please find the notes

  18. curtis.robinson@sbti.com says:

    Hello,

    I have been implementing ECM solutions with Records management capabilities for many years now. When managing electronic records, The main preference I have always seen is to manage records in place within the ECM reporistory, Not move them to a different repository outside of the context of their business unit taxonomy. From what I have seen, MOSS has nearly all of the capabilities to do this without implementing record center.

    You have definable policies for content types and workflows. Auditing is configurable. the only real thing missing that record center has is applciaiton of holds and executing disposition reports.  It seem to me if these functions are present in record center, they could easily be made available in Core MOSS.

    Record center seems to be designed to work in the same way old physical record file rooms do. Once documents are no longer active, they are sent to the file room for retention. This is fine for space management needs when these records are not accessed often. But now days, we there is a need to apply retention policies to Electronic documents as soon as they are created. The retention needs to be managed while the documents are still active. Because of this I can’t see the practicality in moving (or copying) an active electronic document to a seperate repository just so full records management policies can be applied to the document.

    I am currently implementing MOSS to a Corporate legal department and implemeting record center for full records management of legal documents. The users are confused as to why they need to send copies of documents to the record center when they need to keep them in their departmental taxonomy to work with daily. Additionally, and this is the big one, Duplication of records is violation of core records management principles. What happens if an E-discovery order is issued? the corporation must discover active documents in the normal Sharepoint repositories as well as the record center.

    I think you have the tools at hand to make SharePoint a powerful records management platform that functions in line with the need to manage active electronic files without moving them to seperate repository.

    I would be very interested in your thoughts on this point of view as I intend to perform many more SharePoint implementations for my clients. I would like to offer them the best records management functionality as well.

    Thank You

Skip to main content