10 Limitations of Crawled and Managed properties in SharePoint Search Schema

I am generally an optimistic person and prefer to only talk about and mention things that are positive or things that will make others positive or be in a good mood. But once in a while, you have to face reality, and life is not as rosy as we wish it would be. The same applies to my baby, SharePoint. Most of my blogs are about its excellent features and capabilities. However, nobody is perfect (well, except for me, of course 😊). And SharePoint does have some limitations and deficiencies.

In the past, I have already written a post about some important SharePoint limitations you need to be aware of. I even wrote one such post about Teams. Today, I want to document another SharePoint limitations post, focusing on one specific area: SharePoint Search Schema, crawled and managed properties.

What are Crawled and Managed Properties?

Before I proceed with the overview of limitations, perhaps it first makes to explain the terminology. Please check out this post for the comparison between crawled and managed properties.

What is SharePoint Search Schema

Likewise, to get familiar with the search schema, read this article as well.

Limitation # 1: Have to reindex libraries/lists after making changes to mappings/schema

The first thing from a long list of limitations of crawled and managed properties that drives me crazy is that you must reindex the document library every time you create or change managed properties mapping. It is one thing if you have content in one library; it is another if you have many libraries all over the place. I explained how to properly reindex the document library in this article.

Limitation # 2: You can inadvertently overwrite site-level managed properties at the tenant level

The second limitation that can have serious consequences is that the Site Level Search Schema does not “talk” to Tenant-Level Search Schema. To clarify what I mean here, if the Site Owner maps a Refinable managed property at the Site Level, the same property will not appear as mapped at the Tenant Level. Here is an example:

Refinable Managed Property mapped at the site level

The same Refinable Managed Property does not show up as mapped at the Tenant-Level

In pure English, the above limitation means that the tenant-level administrator can inadvertently overwrite the refinable managed property created by the Site Owner at the site level.

By the way, this works fine the other way around. If the refinable managed property is mapped at the tenant level, it will show as mapped at the site level.

Refinable Managed Property mapped at the tenant level

The same Refinable Managed Property does show as mapped at the site level

Limitation # 3: Crawled and Managed Properties naming convention is confusing

The first thing that probably strikes many users new to search schema is how confusing the naming convention of both crawled and managed properties is. For example, below are a few screenshots showing the naming convention of crawled properties and auto-created managed properties.

Example of Crawled Properties naming convention

Example of a Managed Property naming convention

You have some flexibility with managed properties when you create new ones. But you will need to get familiar with their naming convention for crawled and auto-created managed properties. I documented it in this post for crawled properties and this one for managed properties.

Creating an alias is one way to mitigate weird naming conventions on managed properties. I explained how it works here.

Example of an Alias on a managed Property

Limitation # 4: Crawled Property does not change if you rename a column

Another annoying thing you might encounter when mapping properties is that you might not easily find the crawled property to map to. That is because when you create a column on a list/library and then rename it, the crawled property will retain the old name as part of its syntax. Luckily, a nice trick will allow you to find the original column name and, respectively, the proper crawled property. I documented it in this article.

Limitation # 5: You have to be careful not to map to auto-created crawled properties

When you manually create managed properties, you need to be careful not to overwrite auto-created managed properties. I explain automatically-created managed properties here. Examples of those properties are those created by site columns or managed metadata.

For example, the following crawled properties will be produced for the Site Column metadata:

And the following crawled properties will be produced for the managed (Term Store) metadata:

As I described here, theows_q_CHCS_SiteChoice and ows_taxid_LibManaged crawled properties from the screenshots above are automatically mapped to managed properties. So if you decide to create your own managed properties, you need to be careful not to accidentally pick those crawled properties that are already mapped. Instead, you would need to map to crawled properties with ows_ColumnName.

Limitation # 6: Manually created managed properties are not available for all types of data

Here is another one that just baffles me. When you create new managed properties, you can only create ones for Text and Yes/No data types. If you need to create ones for, say, Date columns or Integers, you must rely on the built-in Refinable Managed Properties. I described this all in this post.

Limitation # 7: Different characteristics for refinable vs. manually created

Another limitation that I wish did not exist is the fact that you get a different mix of managed properties’ characteristics for Refinable vs. Manually Created managed properties (check if same for auto). If you are curious about the characteristics I am talking about, check out this article where I explain searchable vs. queryable characteristics, for example.

For example, when you utilize a built-in Refinable managed property to mitigate Limitation # 6, it is not searchable, and its check box is unchecked and greyed out. So if you also need that same managed property to be searchable, you would need to manually create another one and check the searchable checkbox.

Limitation # 8: Managed/Crawled Properties do not show up as mapped in the search schema even though they are!

This is yet another WTF type of limitation. As I mentioned in an earlier post, the auto-created managed properties (those created from Site Columns or managed metadata) are automatically mapped to crawled properties. However, if you check out the search schema, it will look like they are not!

View from the Crawled Properties Screen

View from the Managed Properties Screen (same column)

Mikael Svenson has provided an explanation for this in this article.

With that said, this is a pretty HUGE matzo ball (I am Jewish, so I had to use some of my slang 😊), as this will confuse the hell out of Site Owners and Site Administrators and will lead them to believe that auto-created managed properties are not mapped and might prompt them to create those mappings, which would yield negative consequences for search.

It is important to note that this limitation is only true for system and auto-created managed properties. Refinable and manually created ones DO SHOW the mappings in the search schema!

Limitation # 9: You can accidentally overwrite searchable characteristics when creating custom property

This is kind of related to Limitation # 5. What this is all about is that you inadvertently overwrite the searchable characteristic of the crawled property by mapping it to the managed property that is not searchable. Let me explain.

By default, all crawled properties are fully-indexed. That means that even if you create a regular choice column at the library level, the content of the choice columns will also be searchable. So say you create a Choice column in the library called “Division” with a few choices like Marketing, Legal, Accounting, etc. Once I tag all documents and type in Marketing in the search box, it will return all the documents with a Marketing Tag.

However, suppose I later decide to also create a managed property using built-in Refinable managed property. In that case, I will lose the ability for the tag values to be found via the search box. This is because built-in refinable properties have the searchable characteristic unchecked and greyed out. And since the mapping setting overwrites the fully-index crawled property feature, the result will be the fact that the tags will ne be searchable anymore!

To mitigate the issue, manually create another managed property (not a Refinable one) and enable the searchable check box. Once again, the amazing Mikael Svenson documented this issue on his blog.

Limitation # 10: Limit on the max number of Refinable Properties

Ok, so this one is probably not a limit you need to be too concerned about, but it is an existing limit nonetheless. Regarding built-in Refinable properties, there is a limit to how many you can map. I described them in greater detail in this article, but here is a summary:

• Max of 220 RefinableString properties
• Max of 20 RefinableDate properties
• Max of 50 RefinableInt properties

Most organizations will probably never run out of those, but if you do build lots of custom search pages, etc. – it might be a good idea to be aware of this limit.

In Summary

I do want to finish this post on a positive note. Despite the many weird limitations of crawled and managed properties mentioned above, the search schema still allows us to build custom search experiences and queries. And the good thing is that it is not just a feature available to global admins. Regular Site Owners can also map properties in the site-level search schema, which definitely empowers them!