Skip to main content
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.
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

Multi-select (Enable multi-select mode on a Dropdown field) is meant for flat static picklists. The field editor locks the multi-select switch for automated picklists and for a dropdown that other fields depend on, and each cascade level narrows by a single parent value. See Dropdown field.
Automated picklists require the Business plan or higher to publish and to take submissions live. You can build one on any plan. See Automated picklist and Plans and limits.

​
Browse the types

Static

A hand-authored list of options (a 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. Records that already hold the old code keep it, but it is no longer a valid choice, so editing one of those records later means picking a current option.
  • Label: the human-readable text shown in the dropdown (the Label column in the picklist editor). Safe to change at any time. A record keeps the label it had when it was approved, so relabeling changes only what new submissions show.
  • Versioned with the model: static option edits are draft changes. Submitters see them only after you publish a revision. Automated options are always live, because they come from the source taxonomy’s records, but changes to an automated picklist’s own settings (such as its levels) also wait for publish.
  • The list is closed: submitters pick from the options the published model offers; they cannot add values from inside a form. When a field’s values change too fast for admin curation, use a Text field with Suggest from past entries instead of a dropdown. See Letting submitters enter new values.
  • Option filters: a dropdown can show only a subset of a picklist’s options, set per taxonomy or narrowed further per workspace, so different teams see different slices of the same master list. See Field-reference overrides.

​
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 (as its options, in its Picklist Rules, or for a Text field’s suggestions), or one that has child picklists, cannot be deleted until those references are removed.