🙏 Acknowledging Inspiration

Before diving into Content Types, I want to take a moment to thank Gregory Zelfond for being a true inspiration in the SharePoint community. Every time I considered writing about SharePoint, I would discover Greg had already published in SharePoint Maven a detailed and insightful piece that addressed it so well making me pause my plans with a smile 😊

Even though I’ve worked with the Content Type Hub in several projects, I often found it confusing to set up and wasn’t always sure which best practices to follow. This time, I’ve been given a unique requirement that lets me combine what I’ve learned before with a fresh point of view. It finally feels like the right time to share my experience based on real, hands-on work.

🎯 Looking Ahead: The Content Type [CT] Series Begins

Content Types have always been one of my favorite areas in SharePoint. They sit at the heart of intelligent information architecture - powerful, modular, and scalable. Through this series, I’m excited to share what I’ve learned, especially around configuring global (Tenant Level) site columns, content types, balancing governance with flexibility, and making metadata scalable across sites.

This post marks the first entry in my Content Type [CT] Series, where I’ll dive deeper into practical setups, use cases, and best practices drawn from real-world projects. Stay tuned for more insights as we explore how Content Types can supercharge document management in SharePoint Online.

⚙️ Use Case: Balancing Global Metadata with Local Flexibility in SharePoint Online

In a large or medium-scale SharePoint Online environment, achieving consistency across sites while preserving local flexibility can be challenging. A smart solution is to centrally manage common/global columns at the Content Type Hub but allow site owners to create custom content types locally at the site level.

We manage multiple SharePoint sites across different teams and departments. Each site has unique content needs, yet many metadata attributes like “Department", "Business Unit", "Document Category", "Document Type”, "Document Status", “Document State”, "Document Expiry Date", "Document Retention Code" and “Document Owner” need to remain consistent across all libraries for searchability, reporting, compliance, and automation.

🧠 Why Not Create All Content Types at the Hub?

While centralizing all content types at the Content Type Hub might seem efficient, this approach has several practical drawbacks:

❌ Rigidity: A one-size-fits-all structure ignores the unique needs of individual teams and processes.

❌ Dependency: Updates or changes require IT or SharePoint Admin intervention, creating bottlenecks.

❌ Overhead: Sites may inherit unnecessary content types, leading to confusion and clutter.

Creating and publishing content types from the Content Type Hub means teams must rely on IT or SharePoint Admins for even minor changes. More importantly, not every content type needs to be reused across multiple sites. Many exist purely to serve the workflows of a single department.

That's why we've adopted a flexible hybrid model:

Common metadata columns (like “Department", "Business Unit", "Document Category", "Document Type”, "Document Status", “Document State”, "Document Expiry Date", "Document Retention Code" and “Document Owner”) are created globally for consistency across libraries and sites.
The rest of the content types are unique to each site or team, so creating them locally is a better and more flexible option.

✅ Approach: Mix of Global and Local Design

We apply a clear delineation between globally managed and site-specific metadata. Global metadata ensures tenant-wide consistency, while local design allows agility and ownership.

In our case, the content types we need are specific to a single site and aren’t shared across others. So, building and managing them locally gives us more flexibility and control.

However, when the same content type is needed across multiple sites, publishing it through the Content Type Hub is definitely the right approach.

Since site columns created in the Content Type Hub can’t be published directly, we need to associate them with a content type first. To make global columns available across the tenant, we do the following:

Create global site columns at the Content Type Hub
Build a Global Content Type using the global site columns
Publish the Global Content Type to push both content type and site columns across the tenant
In each site, create local content types using the published global columns and other department-specific fields
Or, simply add the global site columns directly to a library’s default content type if that fits the need

This method allows us to keep governance standards intact while giving teams the freedom to design content types that match their needs creating a scalable and adaptable SharePoint setup.

🏗️ Steps to Configure Global Metadata with Content Type Hub

1. Create Global Columns in Content Type Hub

Go to the Content Type Hub site (https://.sharepoint.com/sites/contenttypehub) and:

Navigate to Site Settings > Site Columns

Create your reusable / common metadata fields here. These site columns become building blocks for content types. These are created once, centrally, and available across all sites.

In our case, the following columns are needed as global columns because they are required across nearly all sites within our tenant.

Department
Business Unit
Document Category
Document Type
Document Status
Document State
Document Expiry Date
Document Retention Code
Document Owner

2. Create a Global Content Type Using Global Site Columns

Go to Site Settings > Site Content Types
Create a new global content type (e.g., "DMS GLOBAL Document") and assign the global columns.

Since site columns created in the Content Type Hub can’t be published directly, we need to associate them with a global content type first. That's why a Global Content Type has been created at Content Type Hub Level.

3. Publish Global Content Types

Select your content type, then click “Manage publishing for this content type” and choose “Publish”. This pushes both the content type and associated site columns across the tenant.

4. Reuse Global Columns in Site-Level Content Types

On destination site:

📍 Go to Site Settings > Site Content Type

You can see the Custom Content Type (DMS GLOBAL Document) right here, this was created at the Content Type Hub and pushed across the tenant.

📍 Go to Site Settings > Site Columns

⚠️ Ohh, you might notice that global columns aren’t showing up in your site, but the custom content type is visible.

No worries! Here’s how to get those columns to appear:

Just go to any Document Library in your site - feel free to create one solely for configuration purposes.
Add the Custom Content Type (DMS GLOBAL Document) to that library
As soon as you do that, the global columns attached to that content type will show up under Site Settings > Site Columns and become available for use

You can now reuse these in local content types or document libraries.

5. Build Local Content Types

Each team or site creates its own content types based on their requirements, using the global columns for consistency. For example:

Knowledge Center Site → “Knowledge Document” Content Type
HR Site → “Employee Document” Content Type

Each department or business process may use a few global site columns but not necessarily all of them. In addition to those global columns, teams also rely on department-specific fields tailored to their unique operations. You can now build site-specific content types using centrally managed global site columns.

6. Apply Local Content Types to Libraries

Site owners attach their local types to libraries or simply apply the global columns directly to the library’s default content type if appropriate.

💡 Note: Please refer to the article for a detailed explanation on how to create a content type in the Content Type Hub > How to make the Content Types available on all SharePoint Sites via the Content Type Gallery | SharePoint Maven

💡 Why This Approach Works

Consistency: Global columns enable consistent metadata usage across sites, making reporting easier and helping enforce organizational policies.
Flexibility: Local site owners can define their own content types tailored to specific workflows, without losing connection to global metadata.
Scalability: New sites can quickly align with tenant-wide standards by adopting shared columns; no need to reinvent content types from scratch.
Governance: Central control over metadata ensures integrity and compliance, while still allowing sites to use it in practical, decentralized ways.
Reusability: Avoid duplication by leveraging common metadata across departments and libraries, keeping the structure clean and maintainable.

💬 Final Thought

By combining global columns with site-specific content types, we’re building a SharePoint architecture that's governed, scalable, and team-friendly.

Using the Content Type Hub doesn't mean you can't customize locally. You get the best of both worlds: global consistency with site-level flexibility. It's an essential strategy for anyone managing metadata across multiple libraries or business units.

📌 Stay tuned—next, I’ll break down what happens when globally published content types are modified locally at the site or library level, and how these changes can impact metadata consistency across your SharePoint environment.

I’d love to hear how others approach metadata governance across libraries. Please share your stories, strategies, and best practices!

Architecting Reusable Metadata (Site Columns) with Content Type Hub