SharePoint Metadata Best Practices

I'm in the middle of writing the first of several white papers for echoTechnology. echoTechnology is keen to provide prescriptive guidance when clients are making sweeping portal changes using its echo for SharePoint product, and this is part of that ongoing effort.

The goal of this particular white paper, on best practices for managing SharePoint metadata, is to help provide a series of specific DO's and DON'T's to help SharePoint Administrators when they are deploying and managing content types and site columns in their SharePoint farms.

I've come up with the following so far:

Goals

• Support the creation of a Single Source of Truth in the portal – where content exists in only one place but can be displayed in multiple places
• Create a consistent taxonomy for the portal
• Centralize the management of this taxonomy
• Ensure this taxonomy can be applied across the portal and across all the environments
• Ensure this taxonomy can be updated as business requirements change
• Users should be able to inherit the core taxonomy and enhance with their particular needs
• Any changes make should be shared with the rest of the business, to reduce duplication

High Level SharePoint Requirements

• Identification and creation of core content types for entire portal
• Centralization of core content types in root of each site collection
• Ability to push centralized content types across the whole portal 
• Centralized content types must be updatable and any modifications can be pushed down to the subsites
• Advanced Search should allow the metadata properties to be specifically targeted
• Content Query web parts should be used to surface this content across the portal using the metadata
• Developers should be able to programmatically use the custom content types without running into problems
• Users must be educated and helped to use these content types and site columns
• Users are still able to apply their own metadata when required by inheriting and adding custom columns

The specific Best Practices in SharePoint I recommend at the moment are:

Creating and Managing Content Types

• Create the content type at the top level of a site collection. This ensures it is visible and can be used across the site collection.
• By default, your content types will be placed in the "Custom Content Types" group. To help manage multiple content types over time, we recommend that you create your own group. Name it after your organization, or give it some other meaningful name.
• Create a “root” content type for each type of Parent Content Type that you plan to use. A root content type is a custom content type that inherits directly from one of the Out-of-the-Box Content Types but that won’t be used directly in the portal. To avoid confusion, give the root content type the name of the parent content type, prefixed or suffixed by “Root”. All of your custom content types should inherit from a root content type. By creating these up front, you reserve the ability to later add one or more columns that all the children content types will automatically inherit. This powerful feature will reduce duplication and help ensure consistency across your content types.
• Create a custom group name for your content types. Name the group after your organization or give it some other meaningful name. This is a useful way to filter content types as the portal grows.
• When adding a new site column to one of your root content types, choosing to “Update list and site content types” will propagate your changes to any inheriting child content types. This is desirable behavior since any changes you make at the top level are by definition required across the business. If you do not wish to push down these changes to child content types, then you should perhaps rethink why you wish to add that column to the root level.
• Don’t create too many core content types. Users will have to pick amongst these, and the more there are the more confusion will set in. Target the 80% of common use cases and let your users create their own child content types to satisfy any additional requirements.
• Don’t include too many metadata columns in your content types. The more effort users have to expend while saving documents, the more dissatisfied they will be. Forrester Research quote: “It was so unusable. Eleven metadata fields! We just stopped using it altogether and started managing our documents on our workstations, another file share, anything to avoid having to use this system.”[1]
• Only create site columns for metadata information that is not likely to be contained in the document itself, and that you intend to leverage. If you won’t be targeting a particular piece of metadata via the Advance Search Properties or via a Content Query Web Part, then don’t force users to fill it in. Later, if you find you need to target these properties, you can add them to the parent content type and push the change amongst all the children.
• However many fields you use, make it as easy as possible for users to populate these. Set smart default choices, and make as many fields optional as you can.
• In the case of Word 2007 documents, you can consider creating a custom Document Information Panel that makes it easy to enter metadata and provides filters and lookups behind the scenes. You can also consider embedding a custom workflow in your content type. It can be set to start when creating a new item, or when the item is changed. When triggered, it can fill in more metadata behind the scenes, perhaps using lookup variables such as the user name and department.
• Use the Link to a Document content type whenever you have content stored elsewhere on the portal or in any other location accessible by a URL. This supports the goal of having a Single Source of Truth. Many organizations use this as part of a system of stub references, which link a front end SharePoint portal with their back-end Document Management systems.

Creating and Managing Site Columns

• Create the site column at the top level of a site collection. This ensures it is visible and can be used across the site collection.
• When adding Site Columns, first try to add from existing site columns. They cover a variety of needs from tracking the Author of an item to a person’s Job Title. It is worth checking whether a similar column already exists. Be aware that several especially common pieces of metadata such as Keywords and Subjects already exist and can be used.
• Description already exists but cannot be found in the list of site columns. Other reserved site columns including Title and Description are kept in a site column group named “_Hidden”. Do NOT rename out of the box Site Columns!
• When possible, favour the Choice site column type which displays a list of values as dropdown lists, radio buttons, or checkboxes. This list will reduce the chance of user error and make your metadata values more consistent.
• Don’t Repeat Yourself – leverage existing metadata such as department and project names from lookups and business data catalogue fields. This ensures when things change, your administrators do not have to modify the values in many locations (which leads to errors and inconsistencies). Because Choice columns usually provide a pre-defined list of options, they are often a good candidate for lookups and business data catalogue fields. Always check to see if the Choice values can be linked to some other centralized source, such as Business Data or list items.
• Lookups and Business Data Catalogue columns are also useful to help delegate list management responsibility. Any user with create or modify permissions on the list, or the equivalent permissions in the BDC application, will be able to adjust the values in the site column without requiring the help of a SharePoint Administrator.
• Do not create Choice values that are too specific – you risk forcing your content authors to “misfile” their content. The file folder is a classic example of a system that causes this sort of grief. If an item could conceivable belong to multiple categories, use the Checkbox Choice column type.
• Create a custom group name for your site columns. For consistency, give it the same name as with the Content Types (above). This is a useful way to filter site columns as the portal grows.
• Take care when renaming Site Columns! SharePoint will store the original name as the Internal Column Name, but display the new column name. This internal column name is also known as the SharePoint Field Name. SharePoint will automatically escape the column name when creating the Site Column. David Hunter provides more information on common escape characters on his blog http://www.davehunter.co.uk/Blog/Lists/Posts/Post.aspx?List=f0e16a1a-6fa9-4130-bcab-baeb97ccc4ff&ID=95[2]. Michael Markel identifies a further limit to SharePoint internal naming: the name cannot be more than 32 characters long[3].
• As a best practice, create a Site Column with a name that contains no special and is no longer than 32 characters. Once you’ve created it, you can rename the column’s Display Name using the special characters and make it any length you like.
• An easy way to find the Internal Column Name is to view the Site Column in the Site Columns Gallery. Its URL contains a Column parameter which is the Internal Name.
• NEVER rename the Title column, as this is a reserved name! Doing so will change the Title display name all over the portal, and attempting to change it back will result in this error: “The Column name that you entered is already in use or reserved”. If you wish to change the appearance of a Title column, you should create your own custom site column and hide the original Title column in all views.

Your Advice, Please!

Because these are best practices recommendations, I would love to have your help:

1. Am I recommending anything that you feel is wrong?
2. What am I missing?
3. How do you centralize and manage your metadata in SharePoint?

Feel free to comment, and thanks in advance!

---

[1] “How To Drive Document Management Adoption”; Kyle McNabb; Forrester, 2006-09-07; p 4.

[2] “Tip - SharePoint 2007 Escaped Column Names”, David Hunter, “Thinking out aloud - Dave Hunter's SharePoint Blog” ; 2008-04-06; http://www.davehunter.co.uk/Blog/Lists/Posts/Post.aspx?List=f0e16a1a-6fa9-4130-bcab-baeb97ccc4ff&ID=95

[3] "Chopped Column Names in Sharepoint”; Michael Markel; Blog; 2007-09-20; http://www.michaelmarkel.com/2007/09/chopped-column-names-in-sharepoint.html