If you’ve created a content type in SharePoint, you may find yourself needing to filter on it in a search web part. In the modern world, this web part is called Highlighted Content. Being able to do this is particularly important if you want to roll up content of a specific type across many sites. This post will walk thru examples of doing this in a world where sites, and the content types within, can be provisioned manually or in an automated fashion.
Although use of content types in one specific library may not be necessary, think big picture. What if we had corporate policies in 3 different sites on our tenant as follows:
- Lending policies stored in the Lending site
- HR policies stored in the HR site
- Travel policies stored in the Travel site
And what if policies in the above sites used the Corporate Policy content type to store their policies? Or… what if the above sites all created their own child Policy content types (Lending Policy, HR Policy, Travel Policy) based off the parent Corporate Policy content type? How could we roll-up all policies of type Corporate Policy for our tenant onto 1 page? This is completely doable, however you need to know how you want to roll them up before you start.
There are specific properties you can use to filter by content type. In a fresh new Office 365 tenant, these are the managed properties automatically generated for you relating to content types:
Here’s an example of content in each of the 3 above managed properties:
- ContentType: application/pdf Project Document
- ContentTypeId: 0x010100A9FCC3401E34944EB9278130E0DC5BB7…
- SPContentType: Project Document
I’ll showcase each of the 3 managed properties in this post.
ContentType managed property
If you’ve manually created content types or haven’t controlled the Id of the content type thru automation, you must use either this managed property or SPContentType to filter by the content type name.
The value in this managed property contains a combination of the mime type name (application/pdf) and the content type name (Project Document). For this reason, you must use the qualifier Contains to filter using the friendly name of the content type. My recommendation is to use the SPContentType managed property instead if you want to filter by the friendly name alone, however the ContentType managed property filter will certainly work.
Here’s the Highlighted Content web part filter required for the ContentType property.
Note: If you’ve created a child content type (Example: HR Policy inheriting from Corporate Policy) and try to use the parent content type name as a filter, it will not return any results for content of the child content type. To do this, use the ContentTypeId filter option discussed below.
ContentTypeId managed property
You can use this managed property if the content type ID has been controlled and therefore consistently configured across all site collections it exists in. Ways to do this are:
- create and publish the content type via the Content Type Hub which ensures the ContentTypeId is the same across all site collections
- create the content type using custom code and thereby controlling the ContentTypeId programmatically
- using Site Scripts and Site Designs, explicitly specify the content type Id in the site script action (image)
If the above techniques are not used, the ContentTypeId will be different in each site collection it’s created in (even if the content type name is the same) and therefore will not work as a cross site-collection filter.
One important thing to know about filtering the Highlighted Content web part by ContentTypeId, is to ensure you are using the Contains qualifier and insert a wildcard after the end of the Id. This is for 2 reasons:
- it ensures any library with content using the content type will be returned since once a content type is applied to a list/library, additional characters are appended to the end of the ContentTypeId
- if a child content type has been created based off a parent content type and you want to filter on the parent content type, this filtering technique will return all content type content inheriting from the parent, including all children.
Example: If you’ve created a child content type (Example: HR Policy inheriting from Corporate Policy) and use the parent content type Id as a filter with a wildcard appended to the end, it will return all results for Corporate Policy and anything inheriting from it, including HR Policy.
Here is the Highlighted Content web part filter:
… where the value for ContentTypeId in this example has an asterisk (wildcard) appended to the end:
SPContentType managed property
The value in this managed property is the “friendly” name of the content type and, unless requirements dictate a ContentTypeId filter is required, is my preferred method for filtering content based on content type. For example, Project Document or Backlog Item. If you’ve manually created content types or haven’t controlled the Id of the content type, you must use either this managed property or ContentType to filter by content type name.
Here’s the Highlighted Content web part filter options required for this property. Note, you can use either the qualifier Contains or Equals to return results since the managed property is the exact name of the content type.
An important reason why Information Architecture planning is important is to ensure you will be able to surface relevant content to the right audience when you need to. Content Types have been around for a long time and will continue to be one of the hallmarks of SharePoint content management. Make sure you know how you’ll want to leverage content types in your organization and that you’re building solutions to be able to deliver results whether the content types were configured with manual or automated provisioning methods.
Thanks for reading.