Some of the techniques I use for testing out columns and content types and then going live with them. First the summary, then some background. Don’t forget, rules are made to be broken!
- Create columns and content types at the top level of a site collection
- Set the internal name of your columns to:
- begin with a lowercase abbreviation (I usually use csw or cswtest)
- use a-z & A-Z, and numbers only if you must
- do not use spaces or special characters
- make it read meaningfully, cswtestProjectName
- When creating columns in the web browse
- name it with the internal name
- save it
- then rename it to the display name
- If using the same columns and content types in many locations, ensure the internal name and GUID are the same everywhere … how? Consider using a content type hub to provision them, or a code-based solution.
- If changing column properties in different locations, do it in the library. For example, when:
- changing the display name
- changing the default value
- hiding a column in one content type and not in another – a common scenario is with the document set content types and columns shared with content types used within the document set
- A column is … a column, just like a column in a table. There are a bunch of different types of column from the standard ones like text, number, currency, date, as to advanced ones like managed metadata
- A content type is a collection of columns used to tag documents or list items with an appropriate set of metadata. Eg “Email” and “Contract” documents have quite different sets of columns.
Three critical column properties
There are three critically important column properties you need to know about:
- Display Name: this is the name you see filling in a content type form, as a column in a View, in fact wherever you look up the column
- Internal Name: this is the behind the scenes name. You can see it if you inspect the URL when editing a column and look for the field value
When doing a migration, all mapping from the source system is done to the internal name of the column
- Unique ID: this is a long set of hexadecimal characters technically known as a GUID. It’s not so easy to get the GUID of a column using the web browser.
When you use the same column in lots of places it is critical that the Internal Name and the Unique ID are the same everywhere. However, the display name can be changed at will, for example if you have the column present in English and Spanish libraries you can use English and Spanish for the display name in each place
Column naming standards
You can see in the URL example above the column name is quite readable. I’ve used a lower-case abbreviation as a prefix, and then a meaningful name, all run together without spaces or special characters, so it is obvious where it starts and finishes.
The abbreviated prefix ensures any sorting by name will group all the Clockwork Software (csw) columns together. It also is useful when looking for the search “managed properties” as you can search for the abbreviation to see just those properties (more on search properties another time)
So, in summary
- Use a short abbreviation as a prefix followed by a meaningful name
- Use only letters and numbers (you must start with a letter)
- Use no spaces and no symbols
When you are testing scenarios consider including “test” in the name as I have with cswtestPerson above.
There are four main ways to create columns:
1. Manually using the web browser.
When you create a column in the web browser the name you use becomes the internal name, however you have no control over the Unique ID. This isn’t a major problem if you create the columns in a content type hub and then “publish” them to other site collections.
To specify the display name:
- first create the column calling it by the internal name. This locks in the internal name
- then go back and change the name. This will update the display name property but leave the internal name unchanged
2. Via a content type hub.
I’ve always liked the content type hub approach as it can all be done with the web browser, I.E. can be implemented and maintained without specialist knowledge. It has its limitations but is often a good fit.
FYI: Content types in a content type hub have an extra set of options you can set – whether to Publish, Republish, or Unpublish them.
- when you publish a content type it is pushed out to every site collection (you can limit which site collections “subscribe” to the content type hub, (but that’s an advanced topic)
- publishing a content type preserves the internal name and unique ID
3. With templates
- using library templates is the historic way to do this, however it is discouraged in later versions of SharePoint
- nowadays the way to do it is to apply templates created using the Microsoft Patterns and Practises methodology. This is usually done with scripts or third-party solutions
- in both scenarios the names and IDs are preserved
4. With scripts and other code-based or third-party solutions
These also preserve the names and IDs.
- Create columns and content types at the top level of the site collection unless you have a good reason not to. This will happen automatically with a content type hub
- If you want to use different default values for a column in different site collections it is best to set the default values in each library. This is because updates from a content type hub, or from scripts, will usually reset the default values in the site definition
- If you want certain columns to be “hidden” within a content type this also must be done within each library
- It is possible to set columns to not display on forms while not making them “hidden”. This property can only be set using code-based solutions.
A typical use-case is email metadata when you are using a solution like MacroView or Harmon.ie that automatically populates To, From, Received time, Subject etc. Users don’t need to be able to edit these fields as they should always reflect the actual details on the email.