What are the killer uses of Content Types for Lists (not Document Libraries)?

Question

I've seen a lot of blogs, articles and discussions across the web that lead me to believe that custom Content Types are must-use functionality in a SharePoint site - especially where no-code customization of SharePoint/MOSS sites are concerned.

However, after a few hours of directed research on the subject, the uses of Content Types (for Lists, not for Document Libraries) don't seem all that impressive to me:

• (1) I can group similar kinds of records (e.g. Tasks and Milestones) in the same List, and assign a custom set of fields (and different choices in those fields) to each kind of record in the List.
• e.g. a Task content type might have “Assigned To” field and a Status field whose choices include “Not Started, In Progress, Done, Waived”; the Milestone content type could skip the “Assigned To” field, and provide a Status field whose choices are “Incomplete, Completed, Waived”.
• However, why not just create separate Lists? One reason to group different Content Types in one List is so that you can create one Workflow and have it process all Content Types in that List. If you had two separate Lists, you’d have to create the Workflow twice, and maintain any updates in two places – big pain in the butt.
• (2) When I have different sets of fields for each Content Type, SharePoint will automatically generate different “New Item” and “Edit Item” forms for each – only showing/requesting the fields that are actually relevant to one content type or another.
• e.g. When I create a new Task item, the input form created by SharePoint automatically includes the “Assigned To” field; when I create a new Milestone item, the input form SharePoint creates does not include the “Assigned To” field, thus making it easier for users (and keeping the data cleaner).
• (3) Workflows per Content Type – while workflows can only be associated with one List, you can also associate a workflow to a Content Type. This gives you two opportunities:
• Create a different workflow with different Actions and Conditions that are appropriate for each Content Type.
• Create a single Workflow that operates on a single Content Type, and use that Content Type in more than one List. (Then you get “same workflow in multiple Lists”, in a certain way of looking at things.)
• (4) I can create a certain type of record in a List, and then configure things so that all records of that “type” are Read-only (i.e. cannot be edited after they’re created).
• (5) Filtered Lookups: http://www.sharepointblogs.com/mossms/archive/2009/07/23/filtered-lookups-across-content-types.aspx

Am I missing something? Is there some usage scenario for custom Content Types in Lists that I'm not seeing, and that makes them a must-use feature of SharePoint for you?

Answer 1

I see them as classes. Why not classify your data?

For example you can attach context menu items or event listeners or workflows to a content type. Or if it turns out you need another fields, just add it to content type and it adds it everywhere data is used.

Answer 2

The reason why they are a must-use feature for me is because I often have the same list deployed in many locations across a site. To make a change to the list columns I can just change the parent content type and all of the lists using that content type are updated.

But also as Janis says it's about classifying your data. Think through the data structure and define it in a content type. That content type can then be deployed wherever required and always updated centrally. This makes management of the data structure consistent, predictable and repeatable.

It's also a good sign that whoever developed the solution paid some attention to planning and matching business requirements with the product. Otherwise it can indicate there has been a tendency to create lists ad hoc which can often end up being a maintenance nightmare.

Answer 3

The points that both Janis and Alex make are good ones. Here are a few of my own:

1. The "class" analogy that Janis draws is a good one. Content types aren't just data -- they're the behavior that goes with that data. This "behavior portability" enables us to stop thinking of SharePoint data as simply sitting in a list. Being list-bound is particularly constraining; content types break that constraint.

2. Content types are hierarchical in nature and support inheritance (as Janis alluded to). You can create as complex a hierarchy as you like, much like a class hierarchy. Content types deeper in the hierachy inherit fields and most code-related elements from higher in the inheritance chain. You can choose to keep parent behavior in a derived type or override it.

3. Something I particularly like about content types (related to behavior portability) is the ability to specify custom forms for viewing and working with data. I'm not talking about FormTemplates which plug into list form pages; I'm talking about a craft-your-own experience. The entire "list-centric" mindset of SharePoint can be turned upside down through well-crafted forms that are tied in via FormUrl elements specified in a content type's XmlDocument structure. A blank ASPX page becomes your canvas if you want it.

At the end of the day, I guess it comes down to this (for me): I can think about data being bound to a list and that list's behavior, or I can think about data being more OOP-like in nature with content types. Microsoft has made a heavy investment in content types within the SharePoint platform, and they've made strong arguments for their use in the information architecture of any site. Choosing not to use them could yield some surprises down the road.

Here's one just as an example: the MOSS Records Center. The "guts" of the MOSS Records Center leverages content types as a routing and sorting mechanism to simplify life (http://blogs.msdn.com/recman/archive/2006/09/12/750034.aspx). If you've got a lot of data without content type classifications and you elect to leverage a Records Center ... ouch.

Here's another example: search. With a well-defined information architecture based on content types, partitioning search scopes can become much easier since content type can be converted to a managed property almost effortlessly. With my current client, we do this to easily identify and categorize content for automatic scope inclusion.

Extreme example: publishing sites. You can't even leverage publishing site features without the use of content types, because all publishing layouts are tied to a content type in order to align list data with layout placeholders.

I could go on, but hopefully this gives you an idea of what content types can do for you both as both a developer and an admin. You certainly don't need to use them, but they do represent quite an improvement over the list-specific data days of WSSv2/SPS 2003.

For what it's worth!