From an end user perspective it looks like there is only one field type that creates only a single taxonomy field in sharepoint; but this is not the whole story behind managed metadata fields. If a managed metadata field will be created SharePoint creates two fields instead. For this post I create a field called “TaxTest” which creates the field itself and a field “TaxTest_0”. I will use this field name for reference.
Let’s take a closer look on both fields that was created
- “TaxTest” Field is type of “TaxonomyFieldType”
- “TaxTest_0” field is type of “Multiple lines of text”
The TaxTest field is basically a lookup field. The target to look up is a hidden list in every site collection called TaxonomyHiddenList. This list only exists once per site collection and stores ever Managed Metadata term that ever was used in your site collection. The list cannot be found in SharePoint because it is a hidden list but can be located using the following URL pattern:
http://<yourserver>/<sitecollection root>/Lists/TaxonomyHiddenList or root site collection.
Field values stored in this field has also the same pattern as lookup fields and look like this: “1;#Test Term”
The “TaxTest_0” field will only store key/value pairs which looks like this:
TestTerm|15017394-438b-4c1d-b710-454c7055cc7
<Term value from Taxonomy Store>|<Term Guid from Taxonomy Store>
That’s all for now from these fields I will continue later on with this.
Taxonomy Hidden List
The taxonomy hidden list has two base functionalities. The main reason is the list and view performance in special and SharePoint performance in general. It is much easier to lookup field values from this list than perform a query against the term store every time the data will be used. So if a new term is added to any list in your SharePoint site collection the value will be added to this list.
The second reasons for this list is that changes to in the Taxonomy Store only have to be done to a single list instead of propagate the values to every list and every list item. I think it is a really smart solution to handle massive updates from the taxonomy store.
If a user change, merge or deletes a term in the term store management a timer job will handle the update to the Taxonomy Hidden list. The timer job is called “Enterprise Metadata site data update”. One timer job exists for ever web application. If a changed term will be added to a list item the update goes directly to the hidden taxonomy list in case the timer job was not executed already.
The field on the list are quite self-explaining. You have some Guid that identifies the values in the term store. The different language values of the term will be stored there too. So again I think it’s quite smart from a performance perspective. The catch all field will be used for queries I think but I’m not sure about this. Documentation also lacks a little bit about that.
As always this list should never be changed or update by any user or code. This list is system managed and therefore should only be changed by the system. You can take a look, browse or query but never change anything.
Field usage in SharePoint
The last question to answer is how SharePoint renders the Taxonomy Fields and where which field will be used.
The TaxonomyFieldType (“TestTax”) field will be used whenever it is necessary to display the values from the TaxonomyHiddenList. This field type behaves like a normal lookup and will be rendered as a lookup.
Usage: Display form of list items and views.
TestTax_0 field which is a “multiline of text” field type will be used to find and resolve the terms from the Taxonomy Store.
Usage: New and edit form of list item.
Current Problem in SharePoint
I currently had a problem with the taxonomy field in general. The problem was that in new and edit form the correct values were shown. After the item was saved or created other taxonomy field values was displayed. What happened was that a term was added to the TaxonomyHiddenList once and after that the value was changed in Term Store Management but the timer job failed to update TaxonomyHiddenList. The strange thing was that in my case I haven’t received any error in SharePoint. Starting the timer job manually also had no effect on the term values in the TaxonomyHiddenList.
This behaviour is a known bug that will be fixed in the June CU. In the meantime Joerg Sinemus from Microsoft has a PowerShell script on his SharePoint blog that fixes this issue and a description of this problem. This script will update all Terms manually using object model by using SyncHiddenList Method.
Conclusion
Taxonomy Fields and Managed Metadata is a really good example on how patterns can be reused. For TaxonomyFields the old really old lookup field pattern was reuse, which I think already, existed in SharePoint 2003. I think and with some addition of out-of-the-box lists and content type really great an additions such Term Stores can be made to SharePoint.
Your blog was very helpful. I now have a better understanding to the taxonomy fields. My organization has been experiencing this problem and I was able to use the script you provided as an interim solution.
This is useful info I wish I had known about before deleting th _0 field thinking it was ambiguous and someone else had created it. Is there a way to recover the field and it’s functionality?
Since deleting the multiline field I can no long update the taxonomy filed using Powershell. Which I was doing successfully till my mistake.
HI, theoretical you might be able to recreate the field but I never tried that in real life.
If the affected column is a site collection column you migh be able to recreate the field on a list by addin the field once again.
You will find on https://cann0nf0dder.wordpress.com/2013/04/01/creating-a-site-column-with-managed-metadata/ how the multiline of text field with the _0 after the name needs to eb configured.
/Stefan