Skip to main content
Goal: a dropdown whose options are the approved records of another taxonomy, so the list grows on its own as new records are approved, with no governance-model change. With one level it is a plain dropdown. Add more levels and it becomes a cascade.

​
What you’ll build

A client dropdown on a Campaigns taxonomy whose options come from the records of a Clients taxonomy. Picking a client stores its code; when a new client is approved, it shows up in the dropdown automatically. This recipe builds the plain, single-level case first. The last step shows how to add a second level to make it a cascade.

​
Prerequisites

  • A governance model you can edit and permission to publish it.
  • A workspace where you can create and approve submissions.

​
Steps

1

Create the source taxonomy

Create a Clients taxonomy with a stable code field (a Terminus ID field, or any field marked unique) plus a Text field client_name and an industry field. Assign it to a workspace.
Use a unique field for the value the picklist reads. If two records share the value the level reads, options can be skipped or look like duplicates. The editor warns you when the root level’s field has no uniqueness check.
2

Add and approve some source records

Create a few Clients submissions and approve them. An automated picklist reads the source taxonomy’s approved records, so there has to be data here before the dropdown shows anything. Drafts do not count.
3

Create the automated picklist

In Picklists, add an Automated picklist. Set its Source taxonomy to Clients. The editor shows the source taxonomy’s records in a grid so you can see what the options will be.
4

Add the level that supplies the options

Click + Level and choose the field whose values become the option codes, for example the Terminus ID or client_name. This is the single level (levels[0]). Optionally set its label field so submitters see a friendly name while the code is stored. A single level makes a plain, non-cascading dropdown.
5

Carry extra context (optional)

In the Advanced section, add industry as an additional field. Additional fields ride along on the chosen option as read-only context from its source record, which is useful for reporting. They never narrow the list.
6

Create the dropdown field

In Fields, add a Dropdown field named client and set its picklist to the Clients automated picklist.
7

Attach and publish

Add the client field to the Campaigns taxonomy and publish the governance model.
8

Make it a cascade (optional)

To narrow clients by a parent value, add a second level. Click + Level, pick region as the root (levels[0]), and keep the client field as levels[1]. Then add a client_region dropdown field, set the client field’s Depends on to it, and the client list narrows to the chosen region. See Cascading dropdowns.

​
Worked example

A single-level automated picklist sourced from a Clients taxonomy, plus the field that uses it: 
- id: clients_picklist
  name: Clients
  type: automated
  source_taxonomy_id: clients_taxonomy
  settings:
    levels:
      - { source_field_id: client_id, label_field_id: client_name }
    additional_fields: [industry]

- name: client
  type: dropdown
  settings: { picklist_id: clients_picklist }
Each level is { source_field_id, label_field_id? }. Here the dropdown shows client_name while the record stores the client_id code. The chosen client’s industry rides along on the submission.

​
Verify

  • Open a new Campaigns submission. The client dropdown lists every approved Clients record, shown by client_name.
  • Select a client. The stored value is that client’s code (its client_id), not the label.
  • Approve a brand-new Clients record, then reopen the Campaigns form. The new client appears in the dropdown with no model change.

​
Gotchas

  • Options come from approved records only. If the dropdown is empty, add and approve source records first. Drafts and rejected submissions do not feed the list.
  • Deleted source records drop out; other statuses stay. The list includes every source record except those whose status is deleted. To remove an option, delete the source record.
  • The source value should be unique. The option code is the value of the level’s source_field_id. If many records share that value, options are de-duplicated to one, which can hide records. The editor warns when the root level’s field has no uniqueness check. Prefer a Terminus ID or a unique field.
  • Submitters cannot add options. allow_additions does not apply to automated picklists, because their options come from records. A new value appears only when a record carrying it is approved. If submitters need to coin values inline, use a static picklist with allow_additions.
  • The source taxonomy cannot be the field’s own taxonomy. An automated picklist cannot source from the taxonomy that contains the field using it.
  • A chosen option keeps a snapshot of its source record. The selected option carries the source record as it looked at submission time, so later edits to that record do not rewrite past submissions. New submissions read the current record.