Skip to main content
A static picklist is a hand-authored list of options that one or more dropdown fields point at. You type the values once, and every dropdown that references the list offers the same choices. It is the most common kind of picklist, and the building block for hierarchical lists too.

​
When to use it

  • You own a bounded vocabulary: goals, regions, product lines, priorities, UTM mediums.
  • The values change rarely, or any change should be reviewed before it ships.
  • You want to attach a readable label to each stored value, not just a raw list of strings.
Do not use a static picklist when the options already live as approved records in another taxonomy. Use an automated picklist so the list stays in sync. If you need cascading choices, you still use static picklists, just linked into a parent and child pair. See Hierarchical.

​
How it works

A static picklist is a named list. Each option has:
  • A code: the value saved on the record. Codes are unique within the picklist (and unique among children of the same parent in a hierarchy).
  • An optional label (the option’s description): the text shown in the dropdown. When absent, the code is shown as its own label.
  • A position: the order the options appear in. You set it by dragging rows in the editor.
When a dropdown uses the picklist, the submitter sees the labels and the record stores the chosen code. The list is closed: submitters pick from the options the published model offers, and a value outside the list fails validation. Only an admin, editing the picklist itself, changes the option set.

​
Building and editing options

You edit options in a spreadsheet-style grid with a code column and a label column. You can:
  • Add rows one at a time, or paste a block of rows straight from a spreadsheet.
  • Reorder options by dragging.
  • Convert a flat list into a hierarchical one when you need cascading choices.
There are two ways to reach the editor. Open the full Picklists area of the governance model and add a new static list, or create one inline from a dropdown field’s settings without leaving the field editor (this inline path builds a flat list). Editing a list applies everywhere that list is used.
You cannot add or change options one at a time through the API. Options are managed as a set inside the picklist itself. There is no per-option “add” endpoint.

​
When submitters need values that are not in the list

There is no setting that lets submitters add options from inside a form. (Earlier versions had an “Allow new values” toggle; it was removed, and a picklist’s option set is now fixed at publish time.) If a field’s values genuinely change faster than an admin should curate them, the field should not be a dropdown: use a Text field with Suggest from past entries instead, which autocompletes from values already approved on records while still accepting free text. See Letting submitters enter new values.

​
Settings reference

Option shape:

​
Example

A flat UTM Sources picklist for the Campaign URL Builder:
Referenced from the utm_source dropdown field:
A submission with utm_source=facebook saves facebook on the record while the form shows the label Facebook. If marketing starts posting on Reddit, an admin adds a reddit option to UTM Sources and publishes; it then appears in every dropdown backed by this list.

​
Gotchas

  • Codes cannot be changed safely. Records hold the code, not an internal id. Renaming a code (say facebook to fb) leaves every record that used the old code without a matching option, so those values no longer show a label. Rename the label freely, treat codes as fixed.
  • Codes are unique per picklist, and per parent. Two top-level options cannot share a code, and neither can two children of the same parent. But two children under different parents can share a code, for example other under both email and social.
  • A static picklist always needs at least one option. You cannot save an empty list and fill it in later.
  • Option edits reach submitters when you publish. Adding, removing, or relabeling options counts as a draft change to the governance model, like editing a field. Submitters keep seeing the previously published option set until you publish. See Publish a revision.
  • Removing an option retires its value. Once you remove an option and publish, a value that was already selected on past records but is no longer an option counts as invalid for new submissions. Re-adding an option with the same code makes it valid again.
  • Renaming the picklist itself is safe. name is only a display label. The id is the stable reference that dropdowns and child picklists rely on.