I’ll start this post with a revised version of “Mikael’s managed property rule of three”, now called “Mikael’s managed property rule of four”:
- Never ever mess with the out of the box managed properties.
- Use automatic/implicit managed properties if possible.
- Map crawled properties (the plain ows_columnname ones) to the RefinableXXYY re-usable properties if possible. And do give them a unique alias for easier management and use.
- If you want the value searchable in addition to refinable, ensure you read Side effect of mapping crawled properties to refinable managed properties.
- Create a custom managed property as last resort – which is only possible for Text and Yes/No columns.
Following these four rules will make your life easier, and help out troubleshooting search issues you might encounter.
Sometimes you think you know it all and then SharePoint search throws you a curveball. It’s been dormant all these years as it’s pretty much an edge case, but knowing this trick you can effectively break SharePoint search experiences quite magnificently :) Sounds fun right?
Note: You need access to the tenant search schema to break search experience globally, or employ this on your own site collections for mayhem and otherwise rendering yourself unpopular.
Breaking search by alias
Ever since SharePoint 2013 shipped we have been given the ability to add alias names to managed properties. The typical use case being you have a custom column in a SharePoint library which you want to use in search as a filter or refiner. You map the crawled property for your column ows_MyColumn to for example RefinableString100 and give it an alias explaining the content, for example DocumentStatus. This allows you to craft queries like DocumentStatus:draft instead of RefinableString100:draft. More readable and more descriptive.
So far, so good. What happens if you name your alias the same name as an existing managed property like Title or LastModifiedTime? It had never occurred to me this was possible, but what happens is that your aliases takes precedence and you have effectively taken over the values for those properties.
The left version in the above image shows the original values while the right shows the crawl date string for the title and last modified date via an alias on RefinableString100.
As you can imagine Microsoft Search and the built-in search experiences takes a dependency on what values to expect for many of the out of the box managed properties. Which means you need to take care when you use aliases to ensure you’re not using a name already in use. The good thing is that the fix is easy – remove the aliases and it all goes back to normal.
I’ll leave it as an exercise for the really curious ones to try this in a demo tenant using the out of the box search UI’s to see what happens.
Breaking search by mapping more crawled properties to existing managed properties
Take a managed property such as SPSiteUrl. The default configuration is to populate it with the value from ows_SPSiteURL, the site collection URL for an item.
There is nothing stopping you from adding more crawled properties to this list, but the option to only use the first and not all values is disabled. The result could end up with the managed property containing multiple values instead of the expected singular value – something built-in search UI’s might not have considered. Because why should you?
The fix is still easy, remove your added crawled property mapping and re-index the content.
Summary
If you didn’t quite get it – don’t do this, even if you can.
This post is about understanding how the alias and crawled property mapping features work. If someone performed a configuration without thinking it thru they can inadvertently break search experiences, and now you can fix it :)
