Skip to main content
An automated picklist sources its options from the approved records of another taxonomy instead of a hand-authored list. As records are approved in the source taxonomy, they become selectable options here automatically, with no governance-model change. With one level it is a plain dropdown. With two or more levels it becomes a set of cascading dropdowns.
Requires the Business plan or higher. See Plans and limits.

​
Plan requirements

You can create, edit, and import an automated picklist on any plan. The plan check happens when the model goes live:
  • Publishing: on a plan without automated picklists, publishing a revision fails while the governance model contains any automated picklist, even one that no field uses. The error names the picklists. On such a plan, the Automated Picklist option in the picklists Create new menu shows a Business feature: blocks publishing until you upgrade badge, and the picklist list marks each automated picklist Blocks publish. Upgrade, or delete the automated picklists, to publish.
  • Submissions: on a taxonomy whose published version uses an automated picklist, a submission cannot be sent for review or approved on such a plan. Saving a draft still works, so no rows are lost, and the submission can go live once the account is upgraded.

​
When to use it

  • The valid values for a dropdown already exist as records in another taxonomy (clients, campaigns, products, assets).
  • You want the option list to grow as that taxonomy grows, without an admin adding each value by hand.
  • You want a cascade (parent then child) whose levels are driven by fields on those records, not by a hand-linked static hierarchy.
Do not use an automated picklist when the options are a fixed vocabulary the admin owns. Use a static picklist instead. New options on an automated picklist only appear when records are approved in the source taxonomy.

​
How it works

An automated picklist has no options of its own. You pick a Source taxonomy, and the options come from that taxonomy’s records. Each level is a field on the source taxonomy:
  • The first level is the root dropdown. Its options are the distinct values of that field across the source taxonomy’s records.
  • Each later level narrows by every selection above it. The second level only offers values from records that also match the first selection, and so on down the chain. This is what produces cascading dropdowns.
  • A single-level automated picklist is a plain dropdown.
When someone opens a form with a dropdown on an automated picklist, the option list is built from the source taxonomy’s records:
  1. Every record in the source taxonomy is considered, except deleted ones.
  2. For each level, the value of the level’s field becomes the option’s code.
  3. If the level has a Label field, that field’s value is shown as the label. Otherwise the code is shown.
  4. Values are de-duplicated, so a value shared by many records appears once.
  5. Any Additional fields ride along on the chosen option as read-only context from its source record (useful for reporting on the submission).
Cascading levels connect to the form much like a hierarchical static picklist: each level is its own dropdown field. In the field editor, pick the automated picklist, then choose which level the field shows under Cascade level. The editor links the field to the dropdown that shows the level above. The difference from a hierarchical list is only the source: the options come from records rather than a list you type in.

​
Settings reference

​
Example

A two-level Clients picklist with Source taxonomy Clients: the first level is the region field and the second level is client_name, with industry under Additional fields. A client_region dropdown shows the first level and a client dropdown shows the second, so picking a region narrows the client list. For the full setup, see the Automated picklist recipe.

​
Gotchas

  • Cascading comes from levels. One level is a plain dropdown; two or more cascade. Each dropdown field shows one level, chosen under Cascade level in the field editor.
  • Publishing needs Business. Any automated picklist in the model blocks publishing on a plan without the feature, even if no field uses it. Delete unused ones or upgrade. See Plans and limits.
  • Deleted source records drop out; other statuses stay. The option list includes every source record except deleted ones. To remove an option, the source record has to be deleted; other status changes leave it selectable.
  • Submitters cannot add options. A new value only appears once a record carrying it is approved in the source taxonomy. If submitters need to coin values inline, use a Text field with Suggest from past entries instead of a dropdown. See Letting submitters enter new values.
  • A selected option keeps a snapshot of its source record. The chosen option carries the source record as it looked when the submission was made, so later edits to that record do not rewrite past submissions. New submissions read the current record.
  • Changing a level’s source field changes its codes. Codes are the values of the level’s field. Repurposing or renaming that field on the source taxonomy changes what new codes look like and can leave older records with codes that no longer match any current source value. Publishing catches a level whose field is no longer on the source taxonomy, but not subtler changes.