Creating site columns is a very easy task. So easy in fact, it can create a bit of a mess if you do not use SharePoint Site Column Best Practices. Site columns have a lot of value for reusability among lists, libraries and applications. They also have a major advantage in that they are automatically added to SharePoint’s search engine for crawling purposes. They can also be added as search parameters down the line, when desired.
SharePoint Site Column Best Practices
As with most things, a little planning goes a long way. Before you go off creating site columns, determine who the owner of the column is. This should be a person, group or team who is the authoritative source on the column. Some may be obvious such as “Project Manager”; others may be more company-wide such as “Target End Date”. Since site columns can be created at a root site collection or within many layers of subsites, it is best to understand what “level” the column should be at.
We typically recommend making all site columns at a root site collection level while utilizing well-named groups (read below), but what if you have numerous site collections where a site column may be useful? This is a more advanced conversation and requires a larger architecture discussion outside of this article.
Before you create a single column, review and organize the existing site columns. SharePoint comes with approximately 100 site columns by default. See which ones make sense for your business. The ones that do, change the group name (read below) so they are cleaning organized and accounted for. You can also rename those columns so they are more aligned with your business needs. A common example of one we rename often is “End Date” – we change it to “Actual End Date” as well as typically add “Target End Date” as a new site column. See how much more useful that is compared to just “End Date”?
One point of confusion with reviewing the existing site columns is there are some which are locked by the system that cannot be updated, even though they clearly are useful fields. You can rename these fields, but you cannot change their column type or change their grouping. Some of these columns include:
- Department (single line of text)
- Priority (single line of text)
- Description (there are 3 descriptions, this is in reference the Single Line of Text description under documents).
How we handle these columns is 1) rename the column to “ZZ [Column Name] so it is clear they are not the “real” site column you want to use 2) add a description to those fields along the lines of “locked system field” to let future admins know what happened to this field and why it is in its current state.
When you create a site column, never use spaces as the underlying system name creates extraneous web characters for spaces. Why is this important? It may not be important initially, but if you ever start to use developers as your applications become more advanced, it takes more effort to account for those spaces and can lead to unnecessary troubleshooting.
After you create the site column, you can simply rename the column to the business name value with spaces.
You can also have the same site column name multiple times, for better or worse. If used properly, this is OK. An example is multi text field. You may want to have a Plain Multi Text field as well as a Rich Text field using the same name. Using the Description section when creating the fields can differentiate why there are multiple fields with the same name. You can also use the Description section to annotate system locked fields (read above).
When you are creating a column, you will be asked what group should the column belong to. There are two SharePoint Site Column Best Practices in this category. First, add an underscore or some special character so your group is at the top of all the site columns. This makes it easy to identify your site columns.
The End Result
While all these best practices may seem like overkill for such a simple task of creating site columns, the end result of using SharePoint Site Column Best Practices is a highly organized information architecture for a given site collection. The administrators will be able to easily locate fields they need and know exactly what they are used for.