Skip to main content
A hierarchical picklist is a static picklist with more than one level. Each option on a lower level belongs to an option on the level above, so the child dropdown only offers the values that fit the parent the submitter already picked. This is how you build cascading dropdowns from admin-curated lists (country then region, medium then source, category then subcategory).

​
When to use it

  • A controlled vocabulary has a natural parent then child shape, and picking the parent should narrow the child.
  • The values are admin-owned and fixed, not pulled from another taxonomy’s records.
Do not use a hierarchical picklist when every option is a peer with no parent. Use a flat static picklist instead. When the cascading values already live as records in another taxonomy, build the cascade with an automated picklist that has more than one level.

​
How it works

You build every level in one editor. Open Picklists, click Create new, and choose Static Picklist. Each column header is a level: In the form, a cascade is two or more Dropdown fields, one per level. Point the first at the top level (Countries) and the next at the level below (Regions). The field editor links the child dropdown to the parent dropdown for you, so create the parent’s dropdown first; until it exists, picking the child level shows “The picklist requires a parent dropdown to be created first.” When someone fills in the form, the child dropdown offers only the options under the parent they picked. Until the parent is filled in, the child shows Select "country" first (naming the parent field) instead of options.

​
Branching hierarchies

A level can have more than one child level, so one parent narrows several dropdowns at once (for example, Channel narrows both Platform and Format). Branching works in forms like any other cascade, but the editor can only edit a single chain. When you open a branching picklist, it is read-only: a notice says how many branches it splits into and to “Edit it with Claude or a JSON import”, a Branch selector shows one top-to-bottom path at a time, and there is no Save button, only Back. To change one, use Claude through a connected AI app, or edit an exported file and import it as JSON, which creates a new governance model.

​
Worked example

The Countries and Regions levels from the hierarchical picklists tutorial, shown the way the editor’s Flat view lays them out: Then create a country Dropdown field on Countries, and a region Dropdown field on Regions. When the submitter picks United States, the region dropdown offers only California and New York. The same setup drives UTM medium then UTM source in the tutorial.

​
Gotchas

  • Codes are unique per parent, not globally. Two children of the same parent cannot share a code, but two children under different parents can. other can exist under both email and social. The editor marks a repeated path with “Duplicate detected”.
  • Check the parent code on every row. The parent sits on the same row as its child, so a typo such as usa instead of us does not raise an error: it creates a new top-level option usa. Switch to Grouped before you save to spot strays. The editor does flag a row whose parent is empty (“All parent levels must be filled”) and a parent whose rows are split up by other parents.
  • Give every row of a parent the same label, or leave it blank. A parent option repeats on each of its child rows, and Save keeps one label for it: the first one it finds among those rows. A row where you left the parent’s label blank does not clear it. If rows of one parent carry different labels, the editor marks them (“Other rows of this parent have a different label”) and Save stops with “Conflicting parent labels”, naming the code.
  • Renaming a parent code replaces that option. In the editor, the children move with it, so the tree looks unchanged. Records that already hold the old code keep it, and after you publish the old code is no longer a valid choice when someone edits those records. Rename a label freely; records keep the label they were approved with.
  • Keep cascading dropdowns single-select. Each level narrows by one selected parent value. The field editor locks Enable multi-select mode on a dropdown that other fields depend on, so a parent cannot be multi-select; keep the child levels single-select too. Use separate fields if you need several values at one level.
  • For record-sourced cascading, use an automated picklist instead. If the cascade should be driven by another taxonomy’s records, build an automated picklist with more than one level. It narrows the same way without hand-maintaining options.