Automatically created managed properties*

Story Time

Several days ago I ran across an article on MSDN that talked about the automatic creation of managed properties in SharePoint 2013. In summary, if you create a site column (not a list column), populate it with data, and run a full crawl SharePoint will create a crawled property AND a corresponding managed property. The crawled property creation isn’t new but in previous versions you had to created the managed property manually. SharePoint 2013 goes an additional step by automagically creating a managed property for that column. My first thought was, “Awesome. That’s one less step I have to take.”

But wait…it gets better. The properties that are automatically created aren’t ordinary managed properties. These properties can return specially formatted values. I immediately began to experiment. I created a site column named “Announcement Description” of type Multiline enhanced rich text. This would allow me to enter HTML. I added that column to a list and began creating list items. Next, I ran a full crawl and checked the search schema. And sure enough, SharePoint created a managed property named “AnnouncementDescriptionOWSMTXT,” just like the article said it would. I later used that managed property in a display template and it returned HTML, just like the article said it would! My next thought was, “I love SharePoint 2013!”

After developing that POC it was time to bundle everything up in a SharePoint solution and deploy at a customer site. I decided to use the declarative approach. Most of my other components had to be deployed to the 15 hive, so I had to use a farm solution. I built the solution, deployed it, and activated the necessary features. My new site column showed up as expected. I went on to use the column in several lists and several items. Afterwards I ran a full crawl. After the crawl completed I checked the search schema for the managed property and to my dismay, the managed property was not there! I ran several full crawls, but SharePoint never did it’s magic.

After days of frustration I moved on to another POC with another declarative site column. This time the solution had to be a sandbox solution. After going through a similar process as above I was stunned (and a bit frustrated) that SharePoint did create a managed property in this scenario.


Note the asterisk. The question is: “Does SharePoint 2013 automatically create managed properties for site columns?” The answer is: “It depends.” Below is a table of different scenarios I’ve tested for creating site columns in SharePoint 2013 and the outcomes.

Creation Approach Solution Type Managed Property Created?
SharePoint UI (browser) N/A Yes
Declarative (elements.xml) Farm No
Declarative (elements.xml) Sandbox Yes
Code (server-side api) Farm Yes
Code (server-side api) Sandbox Yes


In closing, I’m not sure if this is a bug or not. It’s certainly inconvenient and leaves me wondering why. Regardless, I hope this post helps you in your decision making process.

12 thoughts on “Automatically created managed properties*

  1. Pingback: Managed metadata properties in SharePoint 2013 | Radu Tut

  2. Pingback: Managed properties in SharePoint 2013 | Radu Tut

  3. Luis Del Pozo

    Hi Lester,

    This is very strange that the sandboxed solution doesn’t work but I am not surprised. It is MS. They claim everything works, sell the porduct and then patch it (maybe).

    Thanks for the info. It will save a lot of hair pulling.


    1. Andrej


      SourceID is the solution for this problem!!!
      Make Sure that you have StaticName and SourceID defined before you deploy your farm solution into your farm.
      If you change the sourceid property in your field definition after you have added your site column to a list this change wont get to the field definition at list level and the crawl behavior will be still bad.

      To solve the problem update the SchemaXML property of your Column at the list level. Replace the GUID like SourceID with “‘″

      $list.Fields["Farm Col 2 Root"].SchemaXML = “”
      $list.Fields["Farm Col 2 Root"].Update()

      run the fullcrawl after you’ve updated your field at the sitcollection level and at the list level and everything will work as expected.

      1. LesterLester Post author

        I’m not sure I understand what you’re accomplishing here. In your case, you’re using declarative AND code. I’d rather stick with one or the other and not worry about a source id.

        1. Andrej

          Yes you are completely right. I do also prefer to go just one path, code or declarative.
          The code is necessary if you have already deployed your declarative solution, and forgot to put values for StaticName and SourceID in your field definition xml.

          If you declare this XML Attributes in your declarative solution before first deployment you are save and do not need any code.
          Unfortunately VS do not add these attributes to field definition xml if you adds a “new item” in your project and in most cases you would forget to put them in.

  4. Nico

    I addes the source id to my declerative definition, and it doesn’t solve the managed properties problem


  5. BHeinrich

    Is there a solution to this issue? Ran into the same problems with declarative definitions.



Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>