Content types vs. custom list field

Question

This is a question about best practices and the intent of the designers of SharePoint.

I'm pretty new with SharePoint, and have only worked on pretty small projects. I often find myself creating custom lists and libraries. In this specific instance, I have a document library which my users will use to collaborately edit and verify the contents of a large number of Excel spreadsheets. I have a separate list which, using event handlers, tracks the changes done to elements in the first list.

When I do this kind of work, I usually just create a custom list or custom document library where I use the "Create column" menu option to add columns. I almost never use fields from pre-existing content types. I have occasionally created a custom content type for the entire list, but the entire process just seemed more complicated and maintenance-intensive than it needed to be. However, I'm assuming that there is some issue related to scalability or reusability that I'm not seeing here. Is this even a relevant question to ask?

• Are there any compelling reasons why content types/site columns should be used instead of local, custom list fields?
• Are there any compelling reasons why local, custom list fields should be used instead of content types/site columns?
• Are there any deeper problems than just the duplication of functionality when it comes to, for instance, avoiding to use a standard SharePoint list type and instead create a custom list that stores pretty much the same information?

Answer 1

The design intention of content types is to support re-use of the list schema (or behaviours). So if there is a requirement to create a lot of lists with the same structure, which is often the case, then the content type enables this. It would be unacceptable to have to create list schemas individually in this situation and would result in repetitive error-prone work. Usually in large SharePoint sites there is a requirement to enforce some level of consistency in the metadata.

In the case where you just create a single list, and you do not anticipate building similar lists elsewhere in the site, there is no reason to use a content type. You can just create an ad-hoc custom list. The same applies to fields - site columns are useful where you want to create consistent metadata across different content types and lists, but not necessary if you don't have that requirement.

The standard list types are a useful starting point if it makes sense for your custom list. For example a Links list gives you some extra functionality, so if you have something that is more complicated but is, at its core, a list of hyperlinks, this is a good place to start. But there is nothing wrong with creating a custom list if you don't need this.

Answer 2

What Bill (@SPDoctor) said. It depends.

Related to #3, as the solutions you work with get larger, you will tend to split up your solutions across several Site Collections. Since Content Types has site collection scope, this can become a problem if you dont want to have redundant maintenance of your content types.

To solve this you can use the new SP2010 feature, Content Type Hub. CT hub is a managed gallery of content types, that allows you to publish content types across site collections.

Read more here.

Answer 3

I always create Site Columns and Content Types. Harsh experience has told me that anything implemented will probably seen as a cool idea by someone and will request it to be implemented elsewhere on the same site collection.

If you have a hierarchy of content types in use across multiple lists inside web sites, and a change request means you need to, for example, add a Choice to a Choice column that must be propagated across all instances, you can do tht easily with content types.

A request asks you to add that choice to just one list that uses that content type? Also possible, as "List Content Types" are actually instances of the Site Content Type, operating on their own (though they do inherit from the Site Content Type).

Answer 4

To the first question - yes. Some data is common across many places. For example, you might have a 'Financial Quarter' site column, and this could be used in many places; the financial quarter is still the financial quarter whether it's an expense request or a report of some kind, so it makes sense to be able to share that column between types. Conceptually, it's the same thing.

Similarly, content types may be applicable in multiple locations. For example, a 'Travel Expenses' document content type is the same thing whether it's in the 'Sales' team site or 'Engineering' site. By making it the same Content Type, you can find all things by that, well, type of content. You could then easily search for all Travel Expenses (there are a few ways of doing that)

As to why to use local fields or content types (second question) - well, sometimes the above things aren't true, sometimes concepts are particular to a single domain. For example, 'Engineering Work Sheets' might only be used by Engineers, so it makes sense that that might be logcal to their particular site. I don't know that that's compelling - but it is a reason.

The rule of thumb I go by is that if something is only going to be used once, it's okay to have a local list content type/field.