Subscribe via RSS Feed Connect with me on LinkedIn

Content Classification in SharePoint: Content Types vs Metadata

[ 11 ] June 4, 2012 |

There are multiple ways to be able to categorize documents in SharePoint but for most they consider two options:

I have a library that is going to contain different types of documents. I want to be able to tell them apart. Should I create a Content Type for each or should I just use the out of the box Document Content Type and add a column called ‘Document Type’ that shows me my different document types?

Without doubt this is one of the most common questions that all users have when they get onto the SharePoint platform. However its not actually that easy to answer since there are a number of variables involved (yes that is my SharePoint Consultant voice I am speaking with). In this post lets look at some of the things you should consider. Before that lets look at the two ways to classify documents that are commonly used:

Classify with multiple Content Types

image

This way you create a different Content Type for each document that you want to have. The Content Type name corresponds to the different documents you want to create and classify.

When you upload or create a document in this library you choose from a set of Content Types that defines what your document is.

image

Single Document Content Type with additional metadata

image

This way you simply have a single Content Type (most probably the default Document Content Type) and then create a column (the ever present Document Type) that you use to categorize the documents with.

When you create or upload a document into this library you don’t choose a Content Type but you choose a value from the Document Type choice field:

image

Guidelines

So what is the correct choice? Well there really isn’t one right answer and as always it depends on your requirements. Personally I always lean to creating Content Types but that is my personal preference on the matter. What I hope this does show is how you need to have an understanding of your business requirements before you can make a educated choice (much like everything else in SharePoint).

Content Type Guidelines

If you are going down the Content Type route realize that this will give you more flexibility and provides great power. However it is more difficult to implement, will require a bit more training on behalf of users and has some limitations for bulk changes.

The Good

Addition Informational

image

When creating a new type of document you can add some really good information as seen above. This can be extremely useful in guiding users

Different Templates for each Content Type

image

One major advantage is that you can have a template (Word, PowerPoint or any file type) that you attach to a Content Type. So for each of your document types (say Contract, Due Diligence Records and Executive Presentation) can have its own template.

If you go down the single document type with additional metadata route you will not be able to have multiple templates since you only have one Content Type.

Different settings per Content Types

image

If each of your different types of documents needs different Workflows, Information Management Policies such as retention, auditing, bar codes and label you can easily do this by defining separate Content Types.

As above if you go down the single document type with additional metadata route you will not be able to have different options since you only have One Content Type.

Share across Libraries, Sites and Site Collections

image

With the power of Content Type Syndication in SharePoint 2010 you can define your Content Types centrally and then use them across your entire farm. This can be super powerful if you have a number of different types of content that are consistent across your organization.

With the single content type with additional metadata option you could also use this option but you will find that ‘Document Type’ field would need every possible type of document in your organization, quickly making it useless.

Mix different types of content in the same library without sharing all metadata

Something that is often forgotten is that when you have different Content Types in the same library each will have its own set of metadata which can be very useful.

image

If using the other approach you will be creating List columns which means that you don’t have any flexibility in determine which types of documents will have which metadata columns. Basically all of the content in your library will have the exact same metadata which is something that you might not want.

The Bad

Additional Skill Required

Put simply its harder to understand and create Content Types than it is to simply add a column to a Document Library (some people think that this is a lost cause). So additional skills and understanding is required.

Cannot Bulk Edit Content Types Easily

For me this is a huge limitation of using Content Types (by the way has anyone got this to work?). You cannot easily change the Content Type of a document in datasheet view which means that it is really difficult to change your document categories.

Using a simple choice column to categorize documents means that you can really easily change the type of content that it is, simply choose the value and drag it down in datasheet view.

image

However I have heard that you can actually do this then please let me know.

Single Document Content Type with additional metadata guidelines

This route is much easier but it does come with some disadvantages in terms of re-use and lack of flexibility. However considering how easy it is for users to set up it’s a very commonly seen configuration that is performed.

The Good

Easy to set up

The reason that this is so common is that its super easy to set up. A simple column and bang you are underway! Although this might not be as elegant as using Content Types its still a far better approach than trying to categorize items within folders.

image

Easily edit options and bulk change items

By simply using a column to categorize documents power users have the ability to easily add new document types (just add a new choice to the Document Type column). To bulk change items for users they use the Datasheet View to change the column value, thereby changing the type of document.

image

Its all easy, easy, easy! Using Content Types it’s a bit harder to add them to libraries from an administrator perspective and bulk changes are harder to do (if not impossible out of the box??)

The Bad

Not scalable

The issue with this approach is that since you can’t logically have a single choice column that contains a complete listing of all of the possible document types you can have (it would be huge) you get users creating the same ‘Document Type’ column at the Library level over and over again.

This causes issues in search, user experience and doesn’t scale very well to more than a few libraries and sites.

Lack of consistent naming

This is another fairly common issue in that users will create multiple Document Type columns, one for each library for example, and then name content that is conceptually the same in a different way.

For example a contract could be called ‘Contact’ in one library, ‘Customer Contract’ in another and yet ‘Contract – Customer’ in another library. This lack of consistency with options can cause major issues for your users and leads to all sorts of Information Architecture madness.

Conclusion

As you can see the choice of which particular approach to categorize content has a number of different elements that you should consider. However first of all understand your business requirements and then make the appropriate choice.

In some situations Content Types may be overkill for your purpose, yet in others the metadata based approach is simply too limiting. Whatever option you choose make sure you understand the tradeoffs between both options.

Tags: , , , ,

Category: Planning, Requirements and Analysis

About Michal Pisarek: Michal Pisarek is the founder of Dynamic Owl Consulting and a Microsoft SharePoint MVP. View author profile.

Comments (11)

Trackback URL | Comments RSS Feed

  1. Sue Hanley says:

    Michal: This is really great guidance, but I think you miss one of the biggest disadvantages of using multiple content types in a single library – you can’t easily create a single view that shows documents “grouped by” Content Type. With the “ever popular” Document Type attribute, you can, which sometimes makes it easier for users to make the paradigm shift from Folders to Metadata – because the “group by” view looks much closer to folders. (You can “group by” Content Type with a cheat in SharePoint Designer, but the view has to be maintained in SPD, which can be an issue.) I think that there is probably a nice compromise with a “hybrid” approach in certain circumstances – for example, creating a shared document Content Type with the core enterprise document metadata and then creating functional-specific content types for each business function that have a unique “Document Type” attribute with function-specific values.I completely agree that there is no right way to do this, but my experience has been that having lots of content types in a single document library is very confusing for users who typically create documents in Word, not in SharePoint. The upload experience is much easier when you ask users to select a document type rather than a content type. And, if you need to use the Link to a Document content type in your library, it gets even harder to explain and maintain.I completely agree that this is not an easy choice to make, but lately, since I’ve been seeing a lot of challenges with training and adoption when there are lots of content types in a single library, I’m leaning a slightly different way – with a hybrid Content Type with Document Type or just Document Type strategy.

    Sue

  2. Corey Roth says:

    I think a hybrid solution works best most of the time. You get a lot of benefit from creating multiple content types. However, with the content type hub you quickly run into issues if you have too many. If you have too many content types, it can make provisioning time consuming and error prone. I was told recently that you really want less than 100 content types and ideally less than 50. Due to that I tend to create content types when needed (i.e.: seperate retention policy, document template, or the metadata signficantly varies from other types). I then rely on a “Document Type” managed metadata column to help classify everything else.

    Corey

  3. Darren Hemming says:

    Is it not helpful to think of Content Types as more than just ‘document types’? A content type may also contain a number of business-led columns relating to specific business processes.

    So with well crafted content types, you get metadata for free!

    Don’t worry that each CT has its own metadata. Where the CT metadata happens to overlap, then we can build a mega-view (“meta-view”?) which displays the overlapping data. Otherwise, you can create specific views which display results from single CTs only.

    Sue, I believe you can extend all document CTs to be groupable by Content Type. That doesn’t mean you can’t also use the Document Type grouping, but it’s probably more business-useful to group by CT.

    Darren.

  4. jeff says:

    Hi,
    Good analysis :)
    I’d add to content type choice, that it improve the seach experience by allowing the search filter (left filters) or the search site, to be set easily.
    Also, if you plan to modify the interface of sp, using custom action, it will give the option to set this interface modification only for library using a specific content type.

    So me i choose content types :)

  5. Glyn Clough says:

    Hi Michal,

    Re the forum post on editing content types in datasheet view – I’ve just posted a reply. I think you can do this as long as you have the content type column as the first column in the view!

    Cheers,
    Glyn

  6. Dan Helmer says:

    Good article, thanks Michal. Content Types are obviously much more versatile but I like your point that they’re not always needed, so don’t force them in to your implementation!

    To help address the lack of consistent naming could you create one common ‘Document Type’ site column and add it to all your libraries?

    Also, if a decision is made to use multiple content types does it make sense to introduce a ‘Content Type Administrator’ into the organization? This person would handle the creation and management of content types and help educate site admins on when and how to use them.

  7. @sue: Thanks Sue I will add that to the article. It is a shame you can’t group by Content Type without using SharePoint Designer (something that never really made sense to me)

    @Glyn: I swear I have tried this on about 4 environments and can’t get it to work..Not that I don’t believe you but I wonder what is going on. Either way having people enter in the free text of the Content Type and not even having a choice option is pretty bad.

    @Dan: You can add one Document Type site column but if you have many types of documents this list can get quite unwieldy. The other issue is that you wont be able to have it across Site Collections unless you use Content Type Publishing
    The Content Type Administrator would usually be a person in an ECM role, most probably a Records Manager. I do think that it is a role that is needed but I would view Content Types as more than just documents and have it include other types of artifacts such as tasks, links and so forth. In that light I would view this as part of the SharePoint Information Architecture role.

  8. Bobby Chang says:

    Michal, thanks for writing the post.

    I was able to use the workaround in the MSDN link that you referenced: http://social.msdn.microsoft.com/Forums/en-US/sharepoint2010general/thread/b9e0d1ba-318b-4449-abf9-65e526ebc024

    Per the forum, I did the following:
    (1) Remove Type Column from the view
    (2) Change Name to “Name (for use in forms)

    Just did a test on sp2010 environment and works like a charm so far!

  9. Bobby Chang says:

    [UPDATE] I tried the work-around above on another sp2010 environment (Office365 to be exact), but sadly cannot replicate! Perhaps, it got taken care off by Service Pack 1.

  10. Nancy says:

    Great post!! I just used it to help explain the difference to a non-SP user and she ‘got it’ right away.

  11. Ed Gregory says:

    Thanks for this collection of gems. I’ve been trying to get my head around the pros and cons of ct versus column, and you tied it all up.

    I probably should have come here first.

Leave a Reply




If you want a picture to show with your comment, go get a Gravatar.