I recently ran into a couple of interesting scenarios with respect to deploying and using managed metadata fields in a SharePoint Online 2013 solution. I knew from working with farm solutions that when working with this type of fields you start by declaring the taxonomy field, a note field associated with that taxonomy field, a content type and then a page layout or a list definition depending on your needs, similar to the scenarios below.
Scenario 1
For the purpose of this example, let’s create the following managed metadata field and a content type called “News Page”:
Then, after provisioning the artifacts above I programmatically tried to bind the “News Page” content type to a Pages library, using a PowerShell script similar to the one below.
The challenge started here, when I got the exception “A duplicate field name was found”:
My NewsCategoryTaxHTField0 note field was definitely not duplicated in the content type, so why was this exception happening? After a lot of troubleshooting, I decided to remove the note field NewsCategoryTaxHTField0 from the content type since it seemed that SharePoint would create one for me, albeit with a different ID than the one I wanted. After doing that, everything deployed properly, no more exceptions until Scenario 2 came into play.
Scenario 2
Now let’s say we create some other managed metadata fields (WcmSiteType and WcmDepartment) following the same pattern as above, then a content type which will then be declaratively used in a list definition. This is my other content type (Site Directory):
and this is a snippet from my list definition:
I was also able to declaratively provision a list instance based on this definition without a problem, although my note fields are still in the content type. For the time being, I was glad that this scenario worked…until Sal — a teammate of mine — tried to manually add the Site Directory content type to an OOTB list. At that moment, the binding to the list got called by SharePoint and we got:
SharePoint was complaining about the first note field found in the content type, WcmSiteTypeTaxHTField0 which got me back to Scenario 1. Though, when declaratively creating list definitions and list instances, we cannot remove the note fields from content type because SharePoint will not create them for us and therefore we will not be able to save data in the managed metadata fields. This scenario seemed even trickier because I still wanted to be able to declaratively do the binding to the list.
After more troubleshooting and reading about this issue, I found a blog post by Luis Mañez where he mentions that the order of declaring the note field and taxonomy field matters; i.e., note field must be declared before the taxonomy field in order to prevent SharePoint from creating a new one for us.
Conclusion
By simply declaring first the note field and then the taxonomy field in Elements.xml file used to provision them, all the issues above were solved and I could safely add the note field back in the content types and list definitions; the order of these fields in the content type and list definition does not matter.
Nevertheless, the question of why the same approach we started with in scenario 1 and 2 works in a farm solution but not in a sandbox solution still remains.
