SharePoint Content Type bits of tips!

In this post: What is a SharePoint Content Type? · Types of Content Types · When do we use tenant wide content types? · When do we use local / site content types? · How inheritance actually makes specific content types work · Breakdown your content types as specific as possible! · Related reading

What is a SharePoint Content Type?

Just for a recap, a SharePoint content type, as a summary, is a grouping of a data category. It pulls together an item and information about the item. It identifies the type of an item — could possibly be one of many different kinds of files, a document, an Excel workbook, or even a status indicator for a progress report. It could also be a list or a folder. A content type associates this item with key metadata or other information such as a template.

We could think of defining an Announcements content type as an example, and adding it to a custom list. Then, any time someone wants to post an announcement, they just choose the Announcements content type we created from the New Item menu to create one.

Types of Content Types

I’ll name the first type of content type the ‘Tenant wide content type‘. In SharePoint Online, fortunately, as it’s evolved with the hub concept, Microsoft provided a centralized place where we can publish content types and use them anywhere inside the tenant’s SharePoint sites. They’ve reserved a URL called {tenant name}.sharepoint.com/sites/contentTypeHub as the place to create tenant wide content types. From the Content Type Hub we can create reusable content types — useful if you’re planning a list with common metadata that will be deployed across many sites. From there, we can ‘Publish‘, ‘Unpublish‘, and ‘Republish‘ your created content types. Just be sure to finalize your content type before publishing it, because it will give you trouble later when you try to publish and republish changes. Sometimes it takes time before updates to your content types get rolled out to every site’s content type list — one factor that affects how long the republish takes is the number of sites your tenant has.

The second type is the ‘Local / Site collection level content type‘. These are content types that will only be used in the current site collection. That way you won’t be publishing content types that are unnecessary for other sites to have. A sample scenario: for the /sites/IT site collection, we needed an IT-specific custom list meant for user license logs and their expiry dates. If we created it inside the Content Type Hub, we’d be publishing a content type that’s only meant for IT and unnecessary for other sites — HR, for instance.

When do we use tenant wide content types?

There are many cases where this approach is a lot more effective and less exhausting. The types created here tend to be the higher-level ones — the generic or common types. When you’re designing a structure for your organization and your solution involves more than one site, or list items/data will be crossing over from one site to another, I’d recommend creating your content types at a higher level so you can create common, reusable content types that can be published and accessed from any other site inside your tenant. You just create it once, and then it’s good to go. Imagine creating the same metadata on tens or hundreds of sites individually instead — that’s exhausting. Good thing you have this tip.

When do we use local / site content types?

If your solution only needs a single site, or data crossing from one site to another isn’t an issue, then I’d recommend the local approach (just be sure the scope stays small the way you first designed it — if the structure ends up needing to be a lot bigger than originally planned, you’ll have trouble adjusting to different scenarios and changes later on). This approach is also neat — your created content type will only be visible in that site collection, isolated. If the type isn’t meant for other sites, it’s better isolated. We don’t want content types meant only for IT showing up inside the Sales site, right?

How inheritance actually makes specific content types work

The “break it down as specific as possible” advice further down works because of a mechanic worth naming directly: content types in SharePoint form a parent-child hierarchy, and a child content type inherits every column and setting from its parent, on top of whatever it adds itself. Creating a “Birthday Announcement” content type as a child of the “Announcement” type from the example above doesn’t mean redefining Title and Description from scratch — it inherits both automatically, and only the birthday-specific columns (a date field, maybe a recipient name) need to be added on top.

This is also what makes the tenant-wide-vs-local decision from earlier less all-or-nothing than it might first sound: a generic “Announcement” content type published tenant-wide from the Content Type Hub can still have site-specific children built locally underneath it (an HR site’s “Policy Update Announcement,” a Sales site’s “Deal Won Announcement”), each inheriting the shared base fields while adding their own on top — rather than needing to choose one scope for the entire concept. One real constraint worth knowing before relying on this: a content type can be marked Sealed, which locks its own definition against further changes (including from child types) — useful for a base type that absolutely needs to stay consistent everywhere it’s inherited, but worth checking for before assuming a parent type can still be extended.

A child content type inherits every column and setting from its parent — breaking a type down into specific children doesn’t mean redefining the shared fields from scratch.

Breakdown your content types as specific as possible!

As for the earlier example, we created an Announcement content type with metadata for ‘Title‘ and ‘Description‘. That’s a fairly generic content type, right? It still depends on whether it’s enough for what you need — but content types are meant to describe your items as specifically as possible. It really depends on what you actually need. Take the Announcements content type: from it, we can create further content types to describe specific kinds of announcements — a birthday announcement, a wedding, a promotion, a kudos announcement, and plenty more you can think of, each inheriting the base fields per the section above rather than starting over.

SharePoint Content Types: The Good, The Bad, and The Ugly — a deeper look at content types, including the Content Type Hub’s real publishing/propagation cmdlets and how it differs from Hub Sites.
Easy Way to Update a SharePoint Content Type — a real, specific fix for a page whose content type got corrupted, using the concepts covered here.

Now that is one tip! For questions and clarifications, please write it as a comment below. Have a nice day!