---
title: "Taxonomies and option lists"
slug: "taxonomies-and-option-lists"
abstract: "Best practices for deciding when to use a taxonomy and when to use an option list, and how to name them."
---
# Taxonomies and option lists

Navigating taxonomies and options lists is a key aspect of effective schema management. This article explains how to choose between taxonomies and option lists, helping you make an informed choice based on your needs. It also provides best practices for naming these structures, ensuring clarity and consistency.

## Choosing between taxonomies and option lists

Setting up your data model comes with a recurring question: do I use [an option list](https://doc.sitecore.com/ch/en/users/content-hub/create-an-option-list.html "Create an option list") or [a taxonomy](https://doc.sitecore.com/ch/en/users/content-hub/create-a-taxonomy.html "Create a taxonomy")? It is crucial to choose the proper data format to have a high-performing application with the required features.

This section contains recommendations and guidance to help you decide when to use taxonomies in your data model, and when to use option lists.

Use the following table to choose between taxonomies and option lists:

| Precondition | Taxonomies | Option lists |
| --- | --- | --- |
| **You have a long list of values** | Used when you have an extensive list of 50 or more values. Avoid using more than 300 taxonomy values, as this is likely to cause performance issues. | Used when you have a controlled vocabulary list with fewer than 50 values. |
| **You need to set security rules based on values** | Used to apply security model rules based on taxonomy values. For example, *Fruitful* brand approvers can only approve assets from the Fruitful brand, not others. | Can't contain security properties. Used when security rules aren't needed based on values. |
| **You need to inherit your values** | Used to create facets in search pages. | Can't inherit from your data model family tree. For example, if you have an option list in the *M.ProductFamily* definition, you cannot show it as a facet filter on the **Products** search page. |
| **You need to include more information than just the primary values alone** | Can hold additional properties, for example descriptions, as schema definitions. | Can't hold more than the value of the controlled vocabulary, because option lists are simple data sources. |
| **You need a hierarchy with more than five levels** | Have no limits in the number of hierarchy levels they can carry. | Limited to a simple five-level hierarchy. |
| **You need to display data on the entity details page and Search component** | Used for data displayed on the entity details page and **Search** component. | Used for data displayed only on the entity itself. |

## Naming conventions

Naming schemas and taxonomies consistently, logically, and predictably lets you distinguish more easily between similar schemas and taxonomies. Content Hub has a prebuilt data model that includes taxonomies with names that are prefixed with *M* (for example, *M.entityDefinitionName* or *M.TaxonomyName*).

When you define your data model, we recommend that you do the following:

- **Define and apply your personalized naming convention** to your schema and taxonomies, similar to the Content Hub prebuilt model. Start any new definition or taxonomy name with a consistent prefix. It is common practice to keep this related to the name of the application or the customer. For example, the company *XYZ* might name their new taxonomy *XYZ.Taxonomy* or *XYZ.Definition*.
- **Name your relations systematically**. When you define a relation between two definitions, write the name of the parent entity definition first. For example, if you want to relate *Brand* and *Asset* definitions, name your relation *BrandToAsset*. Avoid using periods in relation names.

> [!note]
> Taxonomy names can only contain letters, periods, and underscores.