SharePoint Online (SPO) differs slightly with managed property usage than 2013. Unlike 2013, in SPO the managed property will show however refinable and sortable are greyed out. Microsoft has written out out an approach to having these properties refinable:

When you create a new site column in a SharePoint list, the crawler picks up the name of the site column as a new crawled property. SharePoint automatically maps the new crawled property to a new auto-generated managed property. This auto-generated managed property is by default non-refinable.

If you want to use the property as a refiner in the front-end, you must manually map the crawled property to a managed property that is set as refinable. To create a new refinable managed property in SharePoint Online , you must use an existing, unused managed property, and rename it by using an Alias. There’s quite a few managed properties available for this purpose. They have names such as “RefinableString00” and “RefinableDate19.”

For example, you create a new site column called NewColors, and you want users to be able to use NewColors as an option when they refine on the search results. In the search schema, you choose an unused managed property, for example RefinableString00, and rename the property to New Colors by using an Alias. Then, you map this new managed property to the relevant crawled property.

This is ultimately the only way around this in SPO. Unfortunately when using a RefinableString (or any other refinable stub) a key piece of information is missing. The ID of the term is cut out and the refiner only can use the title of the term. Take for example a 2013 view on the refiner data coming back, after setting the managed property:

Refinement Name: GPO|#94acf744-a494-492b-af95-17b41be7e840
Refinement Count: 1
Refinement Token “#48506697310842”
Refinement Value: GPO|#94acf744-a494-492b-af95-17b41be7e840

Compare this to the SPO RefinableString result:

Refinement Name: MyRefiner
Refinement Count: 1
Refinement Token “#3562400”
Refinement Value:MyRefiner

This is a limitation that I have not seen any such way around. So if you are working with this code programmatically or are witnessing items with duplicate names but tied to different terms showing up for the same refiner, this would be a technical limitation of the SPO platform.

No Comments

There are no comments related to this article.

Leave a Reply

Your email address will not be published. Required fields are marked *