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 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.
  • Click + Level to turn 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.

​
When submitters need values that are not in the list

There is no setting that lets submitters add options from inside a form. A picklist’s option set is 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

A picklist must hold at least one option.

​
Example

A flat UTM Sources picklist for the Campaign URL Builder: A utm_source Dropdown field with Picklist set to UTM Sources shows the labels. A submission that picks Facebook saves facebook on the record. If marketing starts posting on Reddit, an admin adds a reddit option to UTM Sources and publishes; it then appears in every dropdown that uses this list.

​
Gotchas

  • Treat codes as fixed. Records hold the code, not an internal id. Renaming a code (say facebook to fb) and publishing does not rewrite existing records: they keep facebook and the label they were approved with. But facebook is no longer a valid option, so editing one of those records through a submission means choosing a current option. Publishing is also blocked while an option filter or a conditional picklist rule still names the old code (a default value naming it only raises a warning). Rename the label freely.
  • 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, and discarding the draft reverts your option edits too. See Publish a revision.
  • Removing an option retires its value. Once you remove an option and publish, the value is no longer a valid choice. Records that already hold it keep it and keep their label; a submission that edits one of them has to pick a current option. Re-adding an option with the same code makes it valid again.
  • Renaming the picklist itself is safe. Dropdown fields and lower levels stay linked to it.