4 types of Managed Properties in SharePoint Online

A while back, I introduced you to the world of managed properties. I also explained how to create them as well. One thing that is important to understand with the managed properties is that we have 4 distinct types of managed properties that exist in the Search Schema. While I briefly touched on this subject in my earlier article, today, I want to clarify those 4 types of managed properties in SharePoint Online and explain when you would use one or another when configuring your search experience in SharePoint Online.

Type 1: System managed properties

The first type of Managed Properties are those that already exist in SharePoint by default, Out of the Box for the main attributes of SharePoint, and out-of-the-box metadata. Some examples of those Managed Properties are:

• ModifiedBy (Managed Property for the Person who modified an item)
• Created (Managed Property for the date an item was created)
• FileName (Managed Property for the File Name)
• FileType (Managed Property for the File Type)
• SiteTitle (Managed Property for the Site Name)
• Author (Managed Property for the Author of the Item/Document)

Example of “ModifiedBy” Managed Property

Example of “Created” Managed Property

For example, if I follow the Keyword Query Language (KQL) and type in FileType:pdf into the search box, it will provide the search results of all PDF documents on a SharePoint site.

Advantages of auto-created managed properties

• They exist, so enjoy the fact that you do not need to create them

Disadvantages of auto-created managed properties

• None I can think of

Type 2: Automatically created managed properties

The second type of managed properties in SharePoint Online are those created automatically for you based on certain conditions. For example, when you create local list/library columns, you only get crawled properties and have to create and manually map managed properties yourself (something I will describe in the next chapter). However, there are a few conditions when managed properties are made for you automatically:

• When you create your column using managed metadata (Term Store metadata)
• When you create your column at the Site level

I documented all those scenarios and provided additional explanations in this article.

Advantages of auto-created managed properties

• The most significant advantage of auto-created properties is that you do not need to spend extra time looking for the correct crawled properties and mapping them manually. The property is ready for you to be used in search queries.

Disadvantages of auto-created managed properties

• Auto-created managed properties have certain naming convention/syntax that might make them hard to find and manage (unless you create an alias)

Example of an automatically-created managed property with its own naming convention

Type 3: Manually created managed properties

Suppose you either created your columns on a list/library using local columns and not site columns or did not use managed metadata. In that case, that means that you would need to create managed properties manually and map them to the crawled properties. This can be done by site owners if you are tweaking search schema at a site level or within the tenant-wide search schema if you are lucky to be a SharePoint administrator.

Advantages of manually-created managed properties

• Unlike with auto-created managed properties where you get a weird naming convention/syntax, with manually-created ones, you get some flexibility in terms of naming convention (you can create your own name for the managed property)

Example of a Manually-created Managed Property where a “normal” name was chosen and mapped

Disadvantages of manually-created managed properties

• The biggest disadvantage of a manually-created managed property is the fact that you can only create them for 2 types of information: Text or Yes/No. If you, say, need to create a managed property for the Date fields, you would need to rely on Refinable managed properties that I describe below.

Type 4: Refinable managed properties

To mitigate the above limitation about the available data types, Microsoft created a set of built-in managed properties that start with the prefix Refinable. Refinable managed properties exist for other sorts of data types, specifically:

• RefinableString
• RefinableDate
• RefinableInt
• There are a few others as well

Since you might be creating lots of managed properties, each data set/type (i.e., date), has a certain number of those default refinable properties allocated. Specifically:

• RefinableString (start at RefinableString00 and end at RefinableString219 – 220 Refinable String Properties total)
• RefinableDate (start at RefinableDate00 and end at RefinableDate19 – 20 Refinable Date Properties total)
• RefinableInt (start at RefinableInt00 and end with RefinableInt 49 – 50 Refinable Integer Properties total)

So if you would like to create managed properties for all sorts of data types, you would need to utilize those built-in refinable managed properties. Say, for example, you want to create a managed property for the expiration date column you have in various document libraries on your SharePoint sites. For this to occur, you would need to utilize one of the RefinableDate managed properties (i.e., RefinableDate00) and map it to all crawled properties created as a result of Expiration Date columns in your libraries.

Advantages of Refinable managed properties

• They mitigate the limitation we have with manually-created managed property, where you can create managed properties for other types of data (not just Text or Yes/No)

Disadvantages of Refinable managed properties

• There is a limit to how many refinable managed properties you can create, but most likely, you will never reach it
• The biggest disadvantage of a Refinable managed property is that it can inadvertently overwrite the searchable capability of the crawled property. You see, what happens is that by default, all crawled properties are searchable or fully indexed, meaning that if you created a local column on say, a document library, the text inside of the metadata column is also searchable if you type that keyword into the search box. However, if you happen to map a refinable property to that crawled property (i.e., ows_ColumnName), the field will lose its full-text search capability, because, Refinable Managed Properties, have a searchable check box unchecked and greyed out (so you can’t even enable it)! To overcome this, you must create BOTH a refinable managed property (for use in queries) and a manual managed property (for its content to be searchable). I want to thank Mikael Svenson for documenting this phenomenon on his blog. Please check out his article here.