GUID vs Label Only Managed Properties

When working with Managed Metadata (linked terms from the taxonomy), there are two types of managed properties: those that pull the GUID in from the term store (the Unique ID of the term) and those that pull in only the label directly to display the text.

For a full list of Managed Properties for Atlas please see here: Atlas Managed Properties for Search

GUIDs - Overview

Atlas In Focus Filters work with GUIDs because the filter has code which fetches the appropriate label from the GUID. This is extra code in the web part. This means that the labels are translatable into different languages based on the user's language preferences. You are giving the web part the GUID, and then the webpart is working out what labels are related to that GUID (term, from the term store) and will display the correct label in the users correct language. So translations are supported here because ID's are the same regardless of language and are translated directly from the term store via the code in the filter web part for that user. 

This GUID code is actioned through the 'filter type' of 'taxonomy'

Label Only Overview

Label Only properties are static and pull in the specific label of the term. They are not translated as part of the web part as the GUID is not part of the mapping in any way. Hence why the label is static - it's only pulling through the one core label set-up against the term (all terms have to have a label)

If you want to display a tag on an in focus card, using a GUID property will display the ID. This is because, unlike In Focus Filters, the results web part do not handle the translation of a GUID into a label as part of the web part code behind the scenes. You have to give it the label so it can display the label. Hypothetically, if the card COULD take the GUID, each card would need to translate the GUID associated to the content into a label - so if you show 30 results (cards), there'll be 30 calls and translations for each bit of content, impacting performance.

Instead of using a new Refinable set to the label only mapping, instead, you can use the actual Atlas Column name, however both will work.

These labels are fetched and actioned through the 'filter type' of 'Check box'

Showcase & Screenshots

Filters

An out of the box filter web parts look like the below, with the relevant Refinables to the taxonomy already configured

Out out of the box, filters use the GUID only refinable properties and are set to the 'taxonomy' Refiner Template. As discussed, it's fetching the GUIDs and pulling in the translations from the term store as labels:

If you replace Information Type with a Label Only Refinable (RefinableString122 instead of RefinableString145), but leave the Refiner Template on 'Taxonomy'

You can see that Information Type (in between Type of Content and Subject) no longer shows.

However if you alter the Refiner Template to 'Check Box'

The filter will appear and show as expected. However it is not translating any GUIDs and will display the name of the term (label) given to the tag, so these filters would not translate into different languages for different users. 

This means that you can use filters with either GUID or Label Only properties, but they require a different refiner template and label only refinables, bringing limitations when needing to translate into different languages on multilingual platforms.

Cards

I'm using In Focus Flip Cards in this example because you can see how it works out of the box yourself if you would like to explore further. 

The back of a Flip Card shows some managed metadata columns associated to the content out of the box. Below we can see Information Type is being brought in and the relevant tag against this content is being displayed (Guide).

The baseline configuration for these two fields is utilising the column name with the GUID (TaxID), not label only. You can see that the 'template' also says 'Taxonomy'.

If I alter Information Type to the GUID Refinable (RefinableString145) I can keep the taxonomy template in the setting.

And the Information Type still shows. This is because the GUID refinable is also mapped to 'CPDocumentType' and is utilising the GUID from the termstore.

However, if I insert the label only Refinable, similar to the filters example above (RefinableString122)

We can see an error:

This is because the Template is still on 'Taxonomy' so it's expecting to receive a GUID to then translate into a label. But it doesn't get a GUID as part of the back-end mapping, so it errors.

However, if you alter the Template to 'Text' it is now expecting text (label).

So you can now see the correct tag being pulled through, however it's lost some of it's formatting.

This label only refinable, although being shown, would not be translatable into different languages, as it is not translating via a GUID, it is showing the core 'static' value only.

Handlebars

Handlebar expressions cannot use the GUID properties, they must use the label only properties because you are hardcoding in a value, and not relying on a GUID that gets translated by code.

So there may be scenarios where you need to utilise the label only property for the handlebar expression, but then use the related GUID Refinable for the filters.