A picklist is the reusable list of allowed values (options) that a dropdown field 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.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 |
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.Browse the types
Static
A hand-authored list of options (
code plus an optional label). The most common picklist.Hierarchical
A static picklist linked to a parent. Child options narrow based on the parent selection.
Automated
Options sourced from approved records in another taxonomy. Grows as that taxonomy grows.
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.
- 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.
- 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.