Some context
I often work with a records management add-on for SharePoint, Collabware CLM. Collabware CLM, with proper and extensive configuration, enables seamless, transparent, and automatic handling of records in SharePoint while users work normally in a SharePoint portal or team site.
In order to carry out this user-friendly records management, CLM depends on content types and SharePoint columns (metadata) to classify content. Trying to come up with the perfect information architecture that balances users’ and CLM’s requirements involves being creative with columns and content types. In order to achieve more flexibility in dealing with a large number of columns and content types that are created in many Collabware CLM implementation projects, I try to use a mix of local and global columns.
In this post, I will share some of my learnings around the list, site, and content type hub level instances of columns and content types.
Please note this post is not about introducing columns and content types. It is only about documenting some behavior as it relates to the scoped copies of columns and content types. If you want to learn more about content types, columns, and metadata in SharePoint, you can easily find information on MSDN, TechNet, and other online sources.
How are content types (and columns) published from the content type hub?
Content types, when published at the content type hub level are dependent on a set of “content type subscriber” timer jobs that exist for each web application in the farm that subscribes to the content type hub. This job, that is scheduled by default to run every hour, creates copies of all content types that exist in the hub in each of the site collections in the subscriber web application.
Any columns created in the content type hub and attached to a published content type will also be pushed along with the content type.
A bit about the scope of content types (and columns)
- Any content type you create in content type hub will be available to all site collections in subscriber web apps. We can call them global content types as they are scoped at the farm level in most cases.
- When the content type subscriber timer job runs and completes, it creates copies of content types in content type hub in each site collection. These copies of global content types exist at the site collection level. If you create any content types at the site collection level (instead of the content type hub), those content types will be scoped at the site collectionlevel and will only be available to the lists and libraries in that site collection. They will not be available to any other site collections in the web application or to the rest of the farm.
- If you create a new content type in a subsite, it will be available to all lists and libraries—and any sub-subsites—but not to any other subsites or site collections. This content type will be scoped at the subsite level.
- You cannot create a content type at a list or library level. However, you can add any of the content types scoped at global, site collection, or site/subsite level to a list or library that exists in the same scope. When you do add the content type to the list or library, a local copy of the content type is created at the list or library level. This copy of the content type is scoped at the list/library level.
Note: All of the above information about scopes and copies applies similarly to columns as well.
What do all these copies mean?
All these different scopes and copies can provide a lot of flexibility when you are trying to configure content types. They can also result in a lot of confusion and lost metadata and columns if you are not careful.
Essentially, SharePoint will let you edit copies of content types and columns at all of the scopes except the subsite level. You can create columns and content types at the subsite level but you cannot edit subsite scoped copies of higher level columns and content types.
Let’s work through an example to make this (slightly) easier to understand:
- You create a content type in the content type hub called "Finance Document" and (create and) add a choice column called "Document Type" to it
- You publish the content type
- A timer job, “content type subscriber,” will run and create a copy of the "Finance Document" content type at the site collection level. Let’s call this Copy 1 of Finance Document content type.
- You add the content type to a document library.
- A copy of content type “Finance Document” will be created at the library level (in truth it is a child of Finance Document with the same name and columns but mixing copies and child content types can be quite confusing so for the sake of simplicity let us pretend that it is a copy and not a child). Let’s call this Copy 2 of Finance Document.
So now, you have three total instances of the Finance Document content type:
- Original Finance Document Content Type
- Copy 1 of Finance Document Content Type
- Copy 2 of Finance Document Content Type
Why bother with copies of the content types and columns?
While this will probably have limited application for most of the farms but when you run into a scenario that could benefit from scoped copies, it will likely have to do with being able to customize the copies (of columns and/or content types) at a lower level without impacting the copies at higher or similar level.
Taking the above example of Finance Document, it could mean that I can edit the Copy 2 of Finance Document (scoped at the library level) and add a column called "Finance Document Status" to that copy only. It will not be added to Copy 1 or the original content type.
Some observations
Based on my experience in working with content type hub, content types, columns, and their copies, I have some observations here in no particular order that may save you some headache or research time. These should be especially helpful if you ever find yourself in need of editing narrowly scoped copies of columns or content types:
- There is no timer job that publishes columns that you create in content type hub. Only columns that are attached to a content type that is then published will make it to the subscriber site collections. You can create a dummy content type, if needed, to serve as a transport for columns that you want to publish globally.
- The web interface will not let you create columns or content types that have the same display name. Names for columns and content types are a finite resource at each scope and should be used carefully. Try to avoid creating a choice column called "Document Status" with values "Draft, Final" at content type hub level when configuring a site for IT because document status for finance may require values of "approved, signed, superseded" and for communications may require "published, unpublished.” One way to address these differences can be to add a suffix to the column (HR Document Status, Finance Document Status, Communication Document Status). Another can be to create the document column at the site collection level for the department instead of the global level.
- Columns and content types are identified by the system by their internal names or GUIDs and not by display name. So if you were to change the Display name of a column's copy at the site collection level (say from "Finance Document Status" to "Document Status") that name will stay changed even if the global content type is republished at the hub level with additional columns. The only time the name change will revert is if you make changes to the global copy of the same column (change name, choice values, default value, required status etc.) and then publish the content type. For example, if you change the name of column to "Fin Document Status" and then republish the content type, then the name of column in the site collection copy of the column will change to "Fin Document Status" from "Document Status."
- If additional values are added to a local copy of a choice column, these values will survive republishing of the global content type as long as the global column is not altered before any of the republishes. If the global column is altered, it will get published and will remove the additional values added to the local copy of the choice column. However, the values assigned to documents/items will continue to stick around until the properties of the document/item are edited, at which stage the user will be required to select a correct value that exists in available choices.
- Changes to term store values used in a managed metadata column do not constitute changes to the column. Therefore, adding new terms to a term set will not trigger update of the column if the content type is republished.Changing the term set that is used by the column will be a changed to the column property and will trigger an update when the content type is published.
- If a locally scoped original column (i.e. column created at site collection) is added to a content type (or library) and a column with same name is created at global level and added to the global copy of the content type, then the content type (or library) using the local column will have two columns with same name (but different field IDs). This will confuse the users and allow them to add both columns to the views and retain their values separately.
- There is no subsite level copy of columns or content types. You can create new columns or content types scoped at subsite level and they will be available for use in all of the list/libraries/sites in the subsite.
- If you simply add a column to a list/library instead of adding it to the list/library level copy of the content type, then that column does not appear in the edit and display forms for the items in the library. You have to resort to the quick edit (data sheet) view to be able to fill in or update values for the column.
Here are some links from MSDN on this topic if you just can’t get enough of this content type goodness:
Introduction to content types (MSDN)
Site and list content types (MSDN)
Content type scope (MSDN)
Updating content types (MSDN)
Updating child content types (MSDN)