Metadata is a general term meaning “data about data”. It’s not something we only deal with in SharePoint – we do it in our real lives all the time. When we have a box of cables in the garage that’s labeled “Cables”, we’ve used metadata.
What is metadata in SharePoint Online?
If information architecture is the site’s blueprint, metadata is one of the building blocks that helps list, libraries, and sites take shape. More specifically, metadata is a set of data that describes and gives information about other data. In SharePoint Online, metadata can be created using site columns and content types. These can then be applied to lists and libraries to help categorize, sort, label, and filter information. Metadata can also improve your search results by assigning additional information to list and library items.
SharePoint Online provides default content types. From here, you can create custom content types with inheritance from these default content types.
Resources:
What is a content type? | Microsoft Docs
Introduction to content types and content type publishing (microsoft.com)
Where can I build the information architecture for my metadata?
When building the information architecture for your content, there are a few different levels where you can choose to build:
- A list column- only available within that specific list or library
- A site column- available across that site collection
- A tenant column- available across site collections
As a better practice, it is recommended to build all site columns at the site or tenant level. This ensures reuse of the content across different locations. Very often, a content owner may present only 1 data need which may tempt you to build a list column. If they need to reuse that content in the future, you will need to either 1) maintain two list columns leading to additional work and risking duplicate or inaccurate data or 2) build the list columns at the site level, delete the list level columns, and reapply the metadata.
To build columns at the tenant level, you will use the Content type gallery in the SharePoint admin center. Once published, these are available to be added to any site collection. Please note, the Content type gallery previously added all content types to each site collection so a better practice developed to use Site Templates to apply metadata across site collections. Now that you can choose what to pull down on each site collection from the Content type gallery, this better practice is shifting. Please explore the pros/cons of different content type propagation to explore this topic further.
Resources:
Pros/Cons of Different Content Type Propagation in Microsoft 365
Create or customize a content type – SharePoint in Microsoft 365 | Microsoft Docs
Does my information architecture belong at the site or tenant level?
If your metadata will not be used across site collections, you can build it at the site level. If your metadata needs to be available across site collections (and you are not using Site Templates), you should build it at the tenant level through the Content type gallery.
Deciding where to put your metadata is an art and a science. We often find metadata falling into a grey area where it might be used across site collections but there is no clear request for that usage at this time. If you can foresee any reuse of the metadata, a better practice is to build at the tenant level.
A few common examples we see for tenant level metadata are policies, standard operating procedures, and training materials. Each department likely has content that falls into these areas. End users should not be expected to know which department is producing which content. Instead, we want to build the content where the content authors have access and then present the content to end users in a task-based (and often centralized) model. Continuing with our example of policies, there are likely policies in Human Resources and Finance. The end user may not know if Human Resources or Finances owns the Corporate Credit Card Policy so there should be an intuitive path to find policies outside of just those site collections and navigation paths.
What are my content type customization options at the tenant level?
Building content types in the Content type gallery requires thoughtful planning and governance. After determining which content types and site columns support all content in that category (for example, a content type for Policy), it is still possible to customize those content types for one site collection and have all content types in that hierarchy in a centralized view.
For example, we have created a content type for “Policy” that inherits from the SharePoint Online default content types of “Document.” We have a site column for “Effective Date” and we are determining the “Owner” by the Site Name for where the content is saved. In Finance, they want to track the individual who is responsible for the policy as well. You can create a new content type for “Finance Policy” using the Policy content type as a parent. This will enable you to add a column for “Policy Author” to only the Finance Policy but still show all Finance policies where the other policies are centralized. Each content type has a unique content type ID. If you add an asterisk after the parent content type ID in your search query, any content types inheriting from the parent will also show.
Should I make content types for a small number of documents on the site level?
Content types do not need to be complex to be useful. It is clear we need content types when each object has additional information we want to track. What about when the only information we have is the name of the object? Does it still make sense to make a content type? Absolutely. The name of the content type is a piece of metadata. Naming a set of documents will give you more capability in the future to surface and filter the content. Again, all of your metadata also helps search results.
Resource: Content Type Inheritance in SharePoint
Where does the data in my site columns belong?
Site columns have a field type like Single line of text, Multiple lines of text, Date and Time, Currency, Choice, Lookup column, and Managed Metadata. If you have a site column with multiple values, you will need to decide if a site column with the field type of Choice, Lookup, or Managed Metadata is best.
When to use the Term Store
If your list of values is applicable to the entire organization, you should create a term set in the Term Store. This makes the term set available across all site collections. We commonly see the need for term sets for Year, Office Locations, and Departments, as examples.
Once a term set has been created, you can then make a site column on the site or tenant level pointing to that information. Multiple site columns may also point to the same term set. For example, I may use the Year term set in my Finance site collection for a site column called “Fiscal Year.” I can use the same Year term set in my Human Resources site for a site column called “Benefit Year.” On December 31, 2022 when I add in term set values for 2023, 2024, etc. those values will automatically be available in both the Fiscal Year and Benefit Year columns without any additional work.
The Term Store offers centralized management of values that is globally available. It does require establishment of a governance model and special permissions. The permissions can be refined, if needed. If a site owner needs to control one term set, you can give them permission to just that term set.
When to use Lookup Columns
Lookup columns allow you to point one site column to another list or library and pull values from a site column in those locations. You may also choose to bring over additional data from other site columns. This can be very useful when creating complex data structures.
Lookup columns also offer more control around the deletion of values than a choice site column so it can be a better practice to make SharePoint Lists for your choice column values instead of creating a choice column.
When to use Choice Columns
Choice columns should generally only be used when the set of values are considered fixed. Examples may include [High, Medium, Low] or [Liquid, Solid, Gas]. These examples are unlikely to change over the course of time; in effect, they are closed sets.
Once you have used a Choice column value in a column, that value isn’t linked back to the original value the way Lookup columns are. If you were to change or delete the Choice column value, items or documents might still be tagged with the old “orphaned” value. Over time, if the Choice column values change frequently, you end up with values which no longer make sense. For this reason, Choice columns should be used sparingly.
Resources:
What is a site column? | Microsoft Docs
Introduction to managed metadata – SharePoint in Microsoft 365 | Microsoft Docs
Information Architecture – Managed Metadata versus Lookup columns | Microsoft Docs
Emily Mancini 