How Many Content Types Do You Need in SharePoint?
The other day, I got a question form an ex-client about Content Types:
How many content types can we reasonably have in a document management collection for a large organization, with multiple document libraries? I am proposing using around 200 content types. We are 12,000 people in 130 countries, so we are big and complex. Our IT guys say this may be too many and they want to consider using much fewer, with just a metadata column to distinguish between content types. I believe this is ultimately a less powerful approach, but I wanted to check with a real expert such as yourself.
First off, after some quick Binging, I can’t find any mention of a hard technical limit on the number of Content Types. I’m sure that someone out there will tell me some number per something, but in SharePoint 2010, it’s gotten pretty hard to run into technical limits without working at it.
In my opinion, the right number of Content Types is the number that you need. (How’s that for a consultant’s response? But I think it’s the right one.) In looking for limits I ran into one well-written piece (Note: the original link seems to have gone south. Here’s one from the WayBack Machine.) from Stephanie Lemieux of Earley & Associates where she says very similar things to my opinions. (It’s a really good article, which includes discussion with Shawn Shell. I recommend reading it.) In her article, she mentions that they “typically end up with about 10-15 content types for a site of medium complexity”. That’s an interesting range, but it’s really rather arbitrary, and I wouldn’t treat it as any sort of real boundary.
What you certainly wouldn’t want to put in place is a Document Library where your users must choose from dozens of Content Types. (There are exceptions to everything, of course.) What you build *must* make sense to the end users; it’s doesn’t matter much at all whether it makes sense to IT, unless it is going to cause a serious technical issue. (See “First off” above.)
Content Types are an incredibly important piece of any information architecture. They really represent the different “business objects” that you might need to move through your SharePoint environment. They might represent what you currently have as printed forms (Paid Time Off Request, Laptop Upgrade Form, etc.), “light” content (Weekly Project Update, etc.), or significant, meaty documents produced only rarely (Annual Report, Position Paper, etc.). Deciding what should be a new, individual Content Type versus piggybacking on an existing Content Type by varying a metadata value is more art than it is science.
It’s important to keep in mind that Content Types have hierarchical relationships. Every Content Type you create inherits from one of SharePoint’s basic Content Types (Item, Document, etc.). Your Content Types can also inherit from each other. For instance, you might have a Content Type called “Status Report”, with other Content Types called “Weekly Status Report”, “Monthly Status Report”, and “Annual Status Report” inheriting from it. This allows you to inherit the metadata structures of the parent Content Type and add to them for each specific child. Changes to the parent can be applied to all of the children, if desired (and it usually should be).
The key components of a good set of Content Types should be driven by the needs for permissions, metadata, workflow, and what templates you want to provide to your users. If there is uniqueness along any of those dimensions for a particular business object, then it may deserve its own Content Type.
There is certainly library science that you can bring to bear: people with that background tend to be pretty good at this, by training. Sometimes that discipline doesn’t translate as well into the SharePoint realm as it might, so having someone who really understands SharePoint as well is critical to building good information architecture. Creating a strong information architecture should rarely be a one-person effort; you should involve the library science role, the SharePoint role, and lest we forget, the end users.
Also keep in mind that in SharePoint 2010, there is a Service Application called the Content Type Hub. This Service Application allows you to share Content Types across Site Collections, Web Applications, and even SharePoint Farms. (In SharePoint 2007, the scope for Content Types was limited to a single Site Collection.) With the Content Type Hub capability the “E” in Enterprise Content Management (ECM) truly becomes possible.
Note: also posted on NothingButSharePoint.com‘s EndUserSharePoint channel on September 13, 2011.
References:
- Introduction to Content Types (MSDN)
- How to: Customize Content Type Syndication in SharePoint Server 2010 (ECM) (MSDN)
- Plan to share terminology and content types (SharePoint Server 2010) (TechNet)
- SharePoint Content Structure – Let a thousand content types bloom? (Stephanie Lemieux)
- SharePoint 2010 Content Type Hub (Marcel Medina)
From a records management standpoint, you might associate a Content Type with a Record Category. This makes some sense, as placing a document into Records Center routes the document and applies retention based on the Content Type.
http://blogs.msdn.com/b/mcsnoiwb/archive/2009/11/05/sharepoint-2010-records-management.aspx
Thanks for addressing this important topic. From your post I think the following 2 selections are really key:
“What you certainly wouldn’t want to put in place is a Document Library where your users must choose from dozens of Content Types. (There are exceptions to everything, of course.) What you build *must* make sense to the end users”
and
“The key components of a good set of Content Types should be driven by the needs for permissions, metadata, workflow, and what templates you want to provide to your users. If there is uniqueness along any of those dimensions for a particular business object, then it may deserve its own Content Type.”
Although I like Stephanie’s post, I think the number she puts forward (“10-15 content types for a site of medium complexity”) is a little bit dangerous: what if you’re not of medium complexity? I agree with you, Marc, that this is a bit of an arbitrary number and that the number you actually use should be driven by real needs.
I also agree with Scott that the needs for records management may also drive content type selection. There are some nuances: The Content Organizer can operate on the basis of metadata and is not limited to content types. You can drive retention by means of the Content Organizer, separating documents into different folder/libraries on the basis of metadata.
However if you’re trying to use in-place records management, then you need to know that Information Management Policies currently do not take metadata into account; they only operate on the basis of content type, folder or library. So it seems there is a potentially more significant role for content types in this scenario.
In my experience of designing information architectures the number of content types has been anything between 10 and and about 250, so I absolutely agree “that the right number of Content Types is the number that you need”. Bear in mind that some of the content types higher up in your hierarchy may not be visible to end users. Also each content type can have its own document template so this can also be a factor in planning out your types.
I often ask my clients to first look at the number of templates they have and then document the associated metadata they would like to capture. Working backwards (through normalisation) I can usually come up with a good information architecture from that satisfies the business.
As for the question of how many content types. Well this always varies on the complexity of the processes you’re trying to emulate. The fewer processes and ceremony then usually, the fewer content types needed. It stands to reason that a company with high ceremony with ultimately require more features such as workflow, records management tighter permission sets and therefore a more evolved IA so therefore I have to agree that setting any kind of number is a little arbitrary.
I generally stay away from Content Types as a first response, unless it’s immediately obvious that one is needed. If it’s something that’s really going to be reused and you can see the lifecycle ahead of it, then go for it. If it’s foggy and unclear don’t go down this path. CTs are hard to maintain and even harder to upgrade. I would argue they’re just as much pain and suffering in upgrading as a schema change in a database (and probably more so). In 5 years of SharePoint with CTs and 2-3 years on my current gig, I’ve built one (and that was only because another consulting company immediately lept to the CT debate but I think it was a bad idea). I just build custom lists with features and deal with the upgrade/downgrade of them that way. I know it sounds crude but works for me. YMMV.