Shall I create a List Column or Site Column?

One of the first decisions you have to make when you create metadata is whether you will be creating it at the list/library level or the site level. In case you do not understand what I am talking about, let me explain the difference and pros and cons of each approach.

List Level Column

This is the most common method and probably the one you are already following. Essentially, you go the list or library where you want to create metadata, go to, say, library settings, create columns with whatever column types you require, and you are pretty much done. For the purpose of this blog post, I am not going to go into details on how to do this as I have previously documented step by step instructions on how to do this.

Site Level Column

There is one big disadvantage to the above method. Can you guess what it is? Let me tell you. The metadata you create at the list/library level stays local to that list or library. Say, for example, you create a drop-down of department names in a given document library. If you want to use that same list of departments at another library even on the same site, you are out of luck. You have to create a new column, copy and paste the list of departments. Moreover, next time you want to alter a drop-down and, say, add an additional department name – you have to manually do this on all lists. As your SharePoint Intranet grows – this might become a nightmare to manage.

This is where the site column comes in. The idea is that you define your metadata once (at the site level) and then use and reuse on all lists and libraries you wish. If you need to make a change later on to a column, you only have to do this in 1 place!

How to create and use Site columns

Creating and using site-level metadata involves several steps.

Step 1: Determine the site where you will create your site column at

Everything in SharePoint is inherited from top-down and Site columns are no exception. The way it works, the higher in your site hierarchy you will create you site column at – the more sites/lists/libraries will be able to use it. So if you decide to create your site column at Finance Department subsite – only that Finance site plus its subsites will be able to reuse that site column. If you create the site column at the root (top-level site) of a site collection, then all of the subsites in your site collections/Intranet will be able to take advantage of the site column.

At the end of the day, it comes down to each specific situation. If you deal with global metadata like Department names, Client names or Document Types, it might be a good idea to set up such metadata right at the root.

Step 2: Create Site Column

The process of creating site column is very similar to the list column.

1. Once on the site, go to Gear Icon > Site Settings
2. From Site Settings page, click on Site columns
3. You will then see a long list of default site columns that exist in SharePoint – don’t touch any of them, just hit Create to create a new site column
4. Type the name of the column, choose field type, provide other essential data. The process is identical to creating a “regular” list or library column. One exception is the Group Choice. You can leave it as-is in the Custom Groups or create your own – this does not matter much – just helps you “find” your column later on when you add it to a list or library.
5. Click OK at the bottom

Step 3: Add the site column to the list or library

We are not done yet. Though we created a site column, our document library (or a list) doesn’t know about it yet. What we need to do now is associate (add) the site column to a list or library. To do that:

1. Go to the document library (or list) where you want to add that column
2. Click on Library Settings (or list settings)
3. Under the Columns section, click on  Add from existing site columns
4. On next screen, choose the column your want to add and click Add button. This is where the grouping I spoke about earlier comes in, make sure to choose Custom Columns or another group, so you don’t have to scroll through hundreds of columns.
5. You will now see your site column added to the library! Mazel Tov!

Things to be aware with Site Columns

• Column names. Some generic site column names are reserved or used already (i.e. Department, Company). Make sure you have unique names for your columns, otherwise you will get an error message when you try and create a site column. For that same reason, you can’t have same column name on 2 site columns
• Making changes to site columns will impact all lists/libraries that use it. This is the default behavior and the whole reason we went with site columns. You can make a change to a site column (say, add a department name) and not have it propagate through to the lists and libraries that use it, but I honestly don’t know why you would do that (defeats the whole purpose of the site column)
• In some cases, just by reusing site column, might not get you what you need. For example, if say I setup my site column called Department and I have a drop down with a single choice selection, however, in your case you need to be able to tag against multiple departments – then the site column the way it is as set up is no good. In that case, you will need to further customize the site column at the list/library level and allow for multiple selection or create a brand new column at a list or library level.

When to use Site column vs List columns

List Column

• Columns that are specific to the list or library
• Columns that most likely will never be used by anyone else

Site Column

• Columns that carry global (company-wide) metadata, like Department names, Client Names, Document types
• Columns that most likely will be reused by others
• Enterprise or custom search down the road. If, in the future, you think you will be building custom or enterprise search for your Intranet, you are better off creating site columns. That is because when you create site columns, behind the scenes, SharePoint indexes and maps the indexed properties (called crawled properties) to something called managed properties. With list columns, the crawling part does take place, but the mapping to managed properties part does not. In case you are confused by all this technical lingo, I will publish a separate post on the topic down the road. For now, it is just something to keep in mind.