Taking Advantage of the Content Type Inheritance Model in SharePoint

In my recent post Using Content Types in SharePoint’s Site Pages Library, I mentioned using interstitial Content Types, but didn’t explain what I meant.

Taking advantage of the Content Type hierarchy is an important part of a powerful information architecture, regardless whether you’re working with documents, list items, pages, etc. I’ve talked about this in conference sessions for years, but it doesn’t seem like I have a blog post about it.

Let’s use this slide from one of those sessions to illustrate the points.

SharePoint gives us the Document Content Type “out of the box”. Every Document Library you create in SharePoint (assuming you don’t use some fancy template) has the Document Content Type enabled for it. So many people just start dumping their files into the Documents (aka Shared Documents) library with every file becoming a Document and then wonder why no magic is happening.

In the example above, I have two interstitial Content Types. (Interstitial – or interstices – are spaces between things.) I create these interstitial Content Types, but never enable them in a Document Library; they generally only exist to create a strong hierarchy.

• Org Base Document – When I start setting up the information architecture in a tenant, I almost always create a Content Type like this, usually putting the name of the organization in place of “Org”. You may never touch this Content Type again after you create it, but I’ve had it save my bacon multiple times when someone says something like, “let’s add X to ALL our custom Content Types”.
• Contract – This is also a Content Type which I may not ever enable in a Document Library, but it allows me to search for Content Types which inherit from it.

These days, I’m most likely to create Org Base Document and Contract at the tenant level (in the Content Type Hub, via the Content Type Gallery in the SharePoint Admin Center). We use that enterprise level capability for Content Types which *may* be used in one or more sites. It gives us a central place to manage our information architecture – where it makes sense to do so. Since I’m going to inherit from Org Base Document for all my custom Document-derived Content Types, I create it at the tenant level.

When we set up a custom Content Type and inherit from an existing Content Type, there’s a brilliant logic under the covers. The out of the box Document Content Type at the tenant level has its ContentTypeId =0x0101. 0x0101 represents a Document in every tenant. (See: Base Content Type Hierarchy | Microsoft Learn for the full list of base Content Types in SharePoint.)

When I create the Org Base Document Content Type in the Content Type Gallery, it gets a ContentTypeId which starts with 0x0101 and then has a unique GUID-like part. Here is the full hierarchy tree for the Content Types with their ContentTypeIds in my Sympmarc tenant:

Content Type	Inherits from	ContentTypeId
Item	[System]	0x01
Document	Item	0x0101
Sympmarc Base Document	Document	0x0101002FBDBE6A1A315F438E41F10681463A61
Contract	Sympmarc Base Document	0x0101002FBDBE6A1A315F438E41F10681463A6101
Employment Contract	Contract	0x0101002FBDBE6A1A315F438E41F10681463A610101
Real Estate Contract	Contract	0x0101002FBDBE6A1A315F438E41F10681463A610102

As you can see, the inheritance model makes a lot of sense. Each inheritance appends something unique to the ContentTypeId. Once I’ve enabled the appropriate Content Types in Document Libraries (in this case), I can take advantage of the hierarchy using queries like:

Intent	Query
Show me all my custom Content Type -based documents	ContentTypeId:0x0101002FBDBE6A1A315F438E41F10681463A61*
Show me all the Contracts	ContentTypeId:0x0101002FBDBE6A1A315F438E41F10681463A6101*
Show me all the Employment Contracts	ContentTypeId:0x0101002FBDBE6A1A315F438E41F10681463A610101*

Show me all the Contracts is the really powerful query here, IMO. By requesting all content with a ContentTypeId which starts with the Contract Content Type’s ContentTypeId (That’s what the asterisk does for us.), it doesn’t matter if I create a new Content Type inheriting from Contract. The query will automagically continue to do what I want because the next Content Type inheriting from Contract will have a ContentTypeId of 0x0101002FBDBE6A1A315F438E41F10681463A610103. In other words, the ContentTypeId:0x0101002FBDBE6A1A315F438E41F10681463A6101* query will just pick that new content up for me without any adjustment.

Pair this good information architecture with the PnP Modern Search Web Parts, and you can build search-driven experiences which are highly specific, easily maintained, and extremely reliable. This is NOT “just Google”. It’s you building solutions to match the user stories and content needs in YOUR organization.

If you extrapolate from these examples, you probably can imagine some potential hierarchies in your information architecture which may help you create more powerful solutions for your end users. I’m curious about your thoughts, so please comment if you have examples.