> ## Documentation Index
> Fetch the complete documentation index at: https://docs.terminus.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Picklists

> A picklist is the reusable list of allowed values behind a dropdown field. Terminus Hub has static, hierarchical, and automated picklists.

<Info>
  A picklist is the reusable list of allowed values (options) that a [dropdown field](/reference/fields/dropdown) points at. One admin defines the list once, and every dropdown that references it offers the same choices. Picklists keep your campaign vocabulary consistent, so a `utm_source` of `newsletter` always means the same thing across every submission.
</Info>

Terminus Hub has three kinds of picklist. Two of them, static and hierarchical, are hand-authored. The third, automated, draws its options live from another taxonomy's records. Hierarchical is not a separate type under the hood: it is a static picklist that links to a parent, so its options narrow based on what was picked higher up the chain.

## When to use each

* Pick **static** when you own a fixed vocabulary that changes rarely or needs review before it changes (goals, regions, product lines, priorities).
* Pick **hierarchical** when one choice should narrow the next, like medium then source, or country then region. You build it as a parent static picklist plus a child static picklist linked to it.
* Pick **automated** when the options already exist as approved records in another taxonomy, and you want the list to grow on its own as that taxonomy grows.

## Comparison

|                                                   | Static               | Hierarchical                            | Automated                            |
| ------------------------------------------------- | -------------------- | --------------------------------------- | ------------------------------------ |
| Where options come from                           | Typed in by an admin | Typed in by an admin, with parent codes | Approved records in another taxonomy |
| Cascading (one choice narrows the next)           | No                   | Yes, by definition                      | Yes, when you add cascade levels     |
| Admins manage options directly                    | Yes                  | Yes                                     | No, the source taxonomy owns them    |
| `allow_additions` (submitters propose new values) | Yes                  | Yes                                     | No                                   |
| Multi-select dropdown allowed                     | Yes                  | No                                      | No                                   |

<Note>
  Multi-select (`multiple: true` on a dropdown) is supported only for flat static picklists. It cannot be combined with a hierarchical or automated picklist. See [Dropdown field](/reference/fields/dropdown).
</Note>

## Browse the types

<CardGroup cols={2}>
  <Card title="Static" icon="list" href="/reference/picklists/static">
    A hand-authored list of options (`code` plus an optional label). The most common picklist.
  </Card>

  <Card title="Hierarchical" icon="network" href="/reference/picklists/hierarchical">
    A static picklist linked to a parent. Child options narrow based on the parent selection.
  </Card>

  <Card title="Automated" icon="database" href="/reference/picklists/automated">
    Options sourced from approved records in another taxonomy. Grows as that taxonomy grows.
  </Card>
</CardGroup>

## Core ideas

* **Code:** the value saved on the record when an option is chosen. Treat codes as fixed. Renaming a code leaves records that already used the old value without a matching option.
* **Label:** the human-readable text shown in the dropdown (the option's `description`). Safe to change at any time without affecting saved records.
* **Allow new values:** static and hierarchical picklists can let submitters type a value that is not yet in the list. The new value is created as a real option only when the submission is approved. See [Letting submitters add options](/recipes/user-addable-options).
* **Option filters:** a dropdown can show only a subset of a picklist's options, set per taxonomy or overridden per workspace, so different teams see different slices of the same master list.

## Gotchas

* **Hierarchical is built from static.** There is no standalone "hierarchical" type to choose. You create a parent static picklist and a child static picklist that links to it. See [Hierarchical picklists](/reference/picklists/hierarchical).
* **Automated options are read-only here.** You cannot add, edit, or remove an automated picklist's options. They reflect the approved records of the source taxonomy. Change the records to change the options.
* **You cannot delete a picklist that is still in use.** A picklist referenced by a field, or one that has child picklists, cannot be deleted until those references are removed.

## Related

* [Dropdown field](/reference/fields/dropdown)
* [Static picklist](/reference/picklists/static)
* [Hierarchical picklist](/reference/picklists/hierarchical)
* [Automated picklist](/reference/picklists/automated)
* [Cascading dropdowns recipe](/recipes/cascading-dropdowns)
* [Letting submitters add options](/recipes/user-addable-options)