Records Management Feature: Content Types

OK, enough stalling! It’s time to get our hands dirty and introduce some real features in the new 2007 release of SharePoint (where Records Management is a core capability).

We recognized pretty early in our release cycle that there are two ways to organize an electronic records management system: one way is to create folders for each kind of content or event and the other is to have a well defined set of record types and any piece of content can be declared as a specific type of record, regardless of where it is filed. Because we heard of success with both forms of records keeping, we enabled both. To scope today’s discussion, though, we are going to talk about the latter form: organizing records by Content Type. In our 2007 release, we will allow IT administrators and records managers to define, as part of their file plan, the list of record types that they manage within a repository. This record type uses a more generalize feature called a Content Type within SharePoint.

A content type is just what it sounds like: a meta description of content that can include custom properties a retention policy, and an associated set of workflows / business processes. SharePoint is “media type” & file format agnostic, meaning literally anything can be declared as a record of any type. This means that Office documents, PDFs, TIFFs (scanned images), e-mail, instant message conversations, videos, and physical records can all be classified and stored with the content types you create. By creating content types to manage your various kinds of records, it means that anything called a Contract or a Tax Record or an Employee Performance Review will be treated identically and consistently within our records management system. It also allows you to define and manage the definition of a tax records (for example) in a single place and as you review and make changes to that definition, it will be automatically propagated to your records. Because we believe classification is a critical component to the success of any records management system, we’ve enabled a number of other features like record filing and reporting, that help process your records or help you identify if anything is out of policy. This can happen, for example, if you have content “held” (meaning its retention schedule is suspended) or expired (but not approved for disposition), or filed to the wrong part of the file plan.

So, Content Types are pretty simple, right? But it’s important to point out a major implication they have on records management:  Content Types are not a feature of value solely to records managers – many of the capabilities they provide are valuable to end-users and to work-in-progress content. For example, a company may define a “Contract” content type that includes the appropriate required metadata to make it easy to find that contract later, and the appropriate workflows for getting that contract signed off. For that reason, the 2007 release of SharePoint encourages users to specify the “type” of content from the beginning of a content’s life (e.g. from the moment of creation, as shown in the image above). For Records Managers this is terrific news – it means that content in the 2007 release of SharePoint is likely to be classified by end-users long before it is ever declared as a record, so figuring out where each declared record belongs in your file plan becomes much simpler and more consistent.

We chose to introduce content types first, because they are one of the key pieces of technology that controls records. Many of the features that we will be talking about as we go forward, will refer back to content types as the underlying mechanism to manage and process your items uniformly, based on type.

Now for the homework item: within your organization, do you have a well-defined set of records that you manage with an associated retention schedule? If not, I encourage you to start planning this, because regardless of what records management system you ultimately decide to use, this will be a core component.

Lastly, I wanted to ask a question: How do you organize your records? Is your records system organized primarily by folders or by record types? I’d love your feedback on this. Thanks for listening!

Jason Cahill, Lead Program Manager

Comments (24)
  1. Adam Pope says:

    Dear Jason/MS Bloggers,

    Thanks for the post, we’re reading it with interest.

    We’ve found particular problems with content that contains dynamic links.

    For example, one spreadsheet contains inflation data.  Thousands of current spreadsheet records (going back many decades) rely on this data which is always changing.  Will the Sharepoint RM system allow such changes?

    If you have an ‘archive’ that maintains the integrity of electronic documents, how will you cope with documents that change themselves?  Will we be given the option to allow them to change?

    Adam Pope

  2. hef says:

    From a records manager’s point of view, we’d be asking whether you’re going to submit SharePoint for review under DoD 5015.2?  

  3. tcp says:

    …and not just Chapter 2 certification, will you have DoD 5015.2 Chapter 4 certification as well?

  4. Wendy K says:

    We organize our records by, first, selecting the record type (as defined by my company as legal, HR, etc), then a corresponding record function code is selected.

    However, this is all subjective since it is done manually by each employer. Two record types will be treated exactly the same as they have the same disposition, however an employee might not choose the same record type as another employee for the same record.

  5. @ hef, tcp:

    Microsoft has decided to pursue DoD 5015.2 (chapter 2) certification for Office SharePoint Server 2007.

    Stay tuned for more information in a future posting.

    – Ethan Gur-esh, Program Manager

  6. SJ says:

    I understand that SharePoint 2007 has limitations on the number of Content types ie., Only 50 Content types that can be defined. How can I define 300+ content types in SharePoint 2007.

  7. @ SJ:

    I’ve just checked with the SharePoint product team, and there is not a hard limit of 50 Content Types. For all practical purposes, there isn’t a hard limit on the number of Content Types that can be defined — and we can certainly handle more than 300.

    Can you let me know where you saw/heard the "50" number? I’d be happy to help correct any confusion out there about the limitations of Office/SharePoint 2007. 🙂


    – Ethan Gur-esh, Program Manager

  8. Dane says:

    If RM is core to Office 2007, is it intended to produce a test drive of the functionality? e.g. Demonstrating full integration with the  MSsuite and all other formats.

  9. @Dane:

    We are planning to have test drives for the entire Microsoft Office Server System, including the Records Management capabilities discussed on this blog.

    These aren’t online yet, but will be available soon. In the meantime, you can learn more about the Test Drive program (including the location to try out the server products once they’re available) @ .

    And in the interim, you can also get the beta to try out on your own (including guides for how to configure/use the Records Management features) @

    Sorry for the delay.

    – Ethan Gur-esh, Program Manager

  10. SJ says:

    Can I assign more than 1 custom or default content type to a document or folder or a site? For example a "Medical benefits" document can be assigned a content type of "Employee" or "Contractor". How do I handle such scenarios?

  11. Tina Torres says:

    I wonder why you would want two different default policies?  It could easily invoke a conflict.  Which policy applies first and why? Or would you keep the item for the longer of the two periods? What if one policy requires content review and the other doesn’t?

    I would need to understand the business need a bit better to help with the scenario.


    Tina Torres – Corporate Records Manager

  12. @ SJ:

    It’s great to hear that you’re evaluating the Office 2007 system features to see how well they meet your needs. However you should direct these questions to the newsgroups & discussion forums that are part of the Office 2007 Beta program. These forums are specifically intended for providing technical support at the level of detail you’re asking for.

    We’re trying to keep this blog at the level of conceptual / business requirements discussion, rather than being another tech support forum.

    Thanks for understanding,

    – Ethan Gur-esh.

  13. Eddie Geller says:

    Can you still utilise the MOSS RDMS features without office 2007 installed on the client? How does it work with Office 2003?

  14. @Eddie Geller:

    You can certainly use the MOSS Document & Records Management features without Office 2007 installed on the client.

    Most of the features discussed in this blog will work just as well for organizations using the Office 2003 client applications as those with the Office 2007 client applications. Many features have a “better” experience with the Office 2007 applications, but the core RDMS capabilities require only MOSS 2007 on the server.

    In future postings we’ll try to be more explicit about where the Office 2007 client applications are required or beneficial, but here’s the breakdown of client vs. server requirements for our posts so far:

    -Content Types:  With MOSS 2007 & Office 2003 applications, you can still define & use Content Types as described in this post. The Office 2007 client makes it easier for users to see/change Content Type information in the context of the applications, but Office 2003 users can still interact with Content Types via the browser.

    – Document Information Panel: This feature is specific to the Office 2007 client applications. But with MOSS 2007 and Office 2003, you can still create Content Types with rich metadata schema… users will need to fill in that metadata via a browser-based experience, which they’ll only see at “save” time, not from the moment they create the document.

    – Information Management Policies: With Office 2003 & MOSS 2007, you can still define policies on server content, which will be enforced regardless of what client applications are being used. However, Office 2003 users will not see the “user communication statement” when working in the applications.

    – Expiration: This feature does not require the Office 2007 client applications.

    – Auditing: This feature does not require the Office 2007 client applications.

    – Barcode & labels: Barcode & label policies can be configured & enforced for items using only MOSS 2007. However, the ability to automatically add barcodes/labels into documents before they’re printed requires the Office 2007 client applications.

    Hope this helps,

    – Ethan Gur-esh, Program Manager.

  15. Yuri says:

    Hello Jason,

    I think the decision to support both content types and folders for the purpose of document classification is the right one.

    We are busy building the additions to MOSS 2007 for better physical record management, and we will defintely use folders for classification based on locations and content types for semantic classifications.

    We will be happy to provide you as much feedback as you need from our work, and hope you’ll beable to help with advice.

    We also will be glad to share our experience (and our problems) in building the full-featured physical record management system on MOSS 2007.

    Here is an e-mail address, if you decide to contact us directly:



  16. Finally! After much patience on the part of this community, we can now talk about the next big area…

  17. Arno Nel 2.0 says:

    Planning Plan document management Chapter overview: Plan document management What is document management?

  18. So far in this blog, we’ve talked directly about electronic records – the files created in document authoring

  19. edgedev says:

    Thanks for this great blog! I’m just now catching up on the whole thing since I started planning a customer’s MOSS 2007 records management solution in earnest with RTM finally here. Hopefully someone is still watching this topic, because I ran into a BIG question (which I’ll try my best to keep scoped to this big picture forum).

    What would be the best mechanism(s) to share look-up data across site collections (i.e. between collaboration spaces and records spaces)? It seems, given the preferable model of keeping them in separate site collections (as discussed in this blog) that the design of the Content Types being isolated to the site collection (and any of its subsites) is a major limitation.

    What if a Content Type in site collection A (which is the collaboration space) has a look up column based on a list in site collection A. When that Content Type is routed to a given place in site collection B (the records space) what happens to the possible look up values that reside in a list back in site collection A? What if that field wasn’t filled in correctly and the records manager needs to correct it in the records space? Can they still select the right value? Or do you have to build a parallel Content Type / look-up field / data source list in site collection B? And how would you keep the two synced? Do you see my dilemma?

    Am I overlooking something obvious? Sorry if this is too specific for this forum. Thanks!

  20. In the previous post , we covered the basics of what’s involved in e-mail records management and why

  21. Document and Records Management Definition Document Management According to Wikipedia : "A document

  22. Arno Nel 2.0 says:

    Document and Records Management Definition Document Management According to Wikipedia : "A document

Comments are closed.

Skip to main content