Chris’s SharePoint Reflections

Just another weblog

  • Chris Zhong

    IT consultant Australia

  • Advertisements

Archive for April, 2009

The cornerstones of SharePoint information Architecture- Site Column and Content Types

Posted by chrissyz on April 16, 2009

Site columns and content types are the foundation of information architecture planning in SharePoint. It is always best practice to invest your time in the upfront planning site columns and content types when setting up your site collections. Trust me. It will all pay off during the management and maintenance phase for your SharePoint implementation. J

First, let’s review the concepts of site column and content type

Site columns can be thought of as templates; SharePoint offers the ability to create customized site columns when the default document library columns and the Core Document Columns are not enough. The column we created here scoped at the site collection level in the site column gallery. Once it is created, you can use it in any list or library to make the information searchable and manageable through metadata.

Another important point to mention: when you add a site column to a list, the resulting list column has the same field ID as the site column. SharePoint uses this to track which list columns are “children” of a given site column. This enables you to make changes to a site column and propagate those changes out to all the list columns that are children of the site column.


A Content Type is a reusable grouping of site columns that can be utilized by a list or library. This makes it possible to maintain a consistent metadata structure for all documents or items of that type in a Site Collection. A Content Type can carry a workflow, an Information Management Policy and a document template along with the site columns. Whenever the Content Type is associated with a library or list, all of the functionality built into the customization of that Content Type will be available to that library or list. However, you cannot create a column in a content type; rather, you have to create the column, and then reference that column in the content type definition. Because of this, when you add a column to a content type, the content type schema doesn’t contain a <Field> element, it contains a <FieldRef> element


Using a single Content Type in multiple lists allows for consistency in the data structure. The consistency adds to the ability to find those list items through a search across the metadata. Another added benefit of using a Content Type in multiple locations is maintainability. Any changes to the parent Content Type can be passed down to any list that is using that Content Type.

We can either create site columns and content types in a browser or through features. We recommended using the later one just because it is easy to transfer between environments,  develop – test – staging- production, this is especially important in the enterprise application space.And it is not complex. You can reference this article to create site column and content type through features. But there are a couple of gotchas for feature deployment.  First of all, at times, the changes to the site column are not reflected when the Feature is reactivated, even when using the optional -force switch to force all updates. It appears that, even though the Feature was deactivated and the site column was removed from the site, SharePoint has left an orphaned site column in the system, and future changes will not take effect, even though it does not appear anywhere on the site.

The workaround is adding the attribute DisplaceOnUpgrade=TRUE to the <Field> node. This way, SharePoint will update the existing site column the next time it is activated.

Another one is once a feature containing content types is activated, developers can update the Feature and reactivate it to make changes to the created content type. However, changes are not pushed down to other content types that inherit from the one being inherited, nor are the changes pushed onto lists where the content type has been added. The only content types updated are those that are not in use.The workaround will be using SharePoint object model. It provides a method for updating content types, and forcing updates to cascade to other child content types and lists that contain the content types.


Posted in Information Architecture | Tagged: | 1 Comment »