Search has been greatly enhanced in SharePoint 2013, and with this, it has also brought some changes in how managed properties are created, and the scenarios where they are supported.
First of all, it should be noted that managed properties are created automatically only for site columns (documentation here). If you are ever wondering why you don’t see a managed property for your column, this should be the first thing you should check. A scenario like this would be if you add a column directly to your list, instead of first creating it as a site column and only after that adding it to your list.
Crawled properties and managed properties are now getting automatically created once the content is crawled. There are a set of rules after which these properties are generated. Full details and explanation about this can be found here . I have also found a blog post that describes how this has evolved and changed from SharePoint 2010.
Things get interesting once you have columns of more complex type, not just text or numbers. I’ll explain this for a simple HTML column (multiple lines of text field with full html support enabled, or publishing HTML). In this case, you should have crawled properties for raw text of this column, but also for the html content of the column. For this scenario, after a full crawl, you should get something like:
- Crawled property ows_r_MTXT_SiteColumnName mapped to managed property SiteColumnNameOWSMTXT (this contains HTML)
- Crawled property ows_SiteColumnName unmapped to any managed property (this contains column value as text)
The same logic applies to Url columns, User columns, Lookup columns etc. Depending on what you are trying to achieve, you might use the crawled property with column value as text, or the crawled property that contains the unformatted column value.
This sounds great so far, right? And it is, except for one really usual scenario! The common way of provisioning site columns in a solution when building a custom application, with custom columns, content types, lists etc. is declarative (xml and CAML schema). There are other ways to do this (server-side API, client-side API, SharePoint UI) but declarative would be the most common way of doing it in 2007 and 2010.
The strange thing that happens when you provision your custom site columns declarative in a farm solution in SharePoint 2013 is that the managed properties don’t get automatically created. It’s not only the managed properties that don’t get automatically created, but the crawled property that contains the unformatted column value isn’t created also. What you get is only a single crawled property for you column – ows_SiteColumnName. It contains only the column value as text, and it doesn’t have a managed property pair. i have found a blog post on this topic that contains a nice summary which shows when the managed properties are created depending on your creation approach.
Even if you don’t plan to use your custom site columns in search in the beginning, maybe in the future you will also want to support this. Therefore, for all scenarios, I would currently drop the declarative provisioning of site columns in SharePoint 2013 and go for server-side/client-side API. You can still use the xml and CAML schema, and take advantage of the SPFieldCollection.AddFieldAsXml method.