> ## Documentation Index
> Fetch the complete documentation index at: https://docs.terminus.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Picklist structures

> A field guide to the four picklist structures (simple, linear cascade, branching cascade, conditional) and the two option sources (static and automatic).

<Info>
  A picklist is the set of approved values a dropdown can offer. Two independent decisions shape every one: what **structure** it has, and where the **options come from**. This page is the decision guide; the [picklists reference](/reference/picklists) covers the mechanics of each type.
</Info>

## 1. Simple

One flat list, no dependency on anything else. A `Medium` picklist with seven options (`paid_social`, `cpc`, `email`, `display`, and so on) shows every marketer, on every campaign, the same seven.

**How it is built:** in the grid editor, as a single column of options. See [static picklists](/reference/picklists/static).

## 2. Linear cascade

A chain where each list narrows the next: one parent, one child, a single path from general to specific. This is the workhorse of paid-media taxonomy: Channel narrows Source, Source narrows Placement. Pick `paid-social`, and Source offers only `linkedin`, `meta`, and `reddit`; pick `linkedin`, and Placement offers only the four options valid under it.

Three behaviors make the cascade safe to fill:

* A child dropdown stays locked until its parent is answered, so there is no wrong fill order.
* Changing an upstream answer clears the downstream ones rather than leaving a stale value.
* The same value can live under two parents. `feed` under `meta` and `feed` under `reddit` are separate options, so you never need workarounds like `meta-feed`.

**How it is built:** the same grid editor as a simple picklist, with multiple levels. Each level is a column, and the column to its left sets the parent. See [hierarchical picklists](/reference/picklists/hierarchical) and the [cascading dropdowns recipe](/recipes/cascading-dropdowns).

## 3. Branching cascade

One parent narrows several children at once. The children are siblings, not a chain: each depends on the same upstream answer, and none affects the others.

```mermaid theme={null}
flowchart LR
  subgraph Linear
    C[Channel] --> S[Source] --> P[Placement]
  end
  subgraph Branching
    CT[Campaign type] --> O[Objective]
    CT --> A[Asset type]
    CT --> B[Budget owner]
  end
```

A field event and a demand-gen program have different objectives, assets, and owners, so one `Campaign type` answer reconfigures the whole section: switch it from `field-event` to `demand-gen` and Objective, Asset type, and Budget owner all reload together. Choosing an asset type does nothing to Objective; only the shared parent matters.

**How it is built:** branching works end to end for people filling in forms, but the grid editor currently builds one chain at a time, so a branching structure is set up by governance-model import or the API today. Your Terminus contact can do this with you.

## 4. Conditional

Instead of narrowing one list, conditional **swaps the list entirely**. You set a default picklist plus ordered rules, each saying "when these conditions hold, use this other picklist"; the first matching rule wins. Use it when a situation needs a genuinely different vocabulary, not just fewer options. EMEA display inventory is not a subset of the global placements list; it is its own approved set.

|              | Cascade                                     | Conditional                                                    |
| ------------ | ------------------------------------------- | -------------------------------------------------------------- |
| What changes | One list, filtered by a single parent field | Several separate lists, one selected                           |
| Conditions   | The parent selection                        | Can combine several fields (`region=emea AND channel=display`) |
| Governance   | Options are siblings in one vocabulary      | Each list is governed on its own                               |

**How it is built:** not in the picklist editor at all. Conditional is a set of rules attached to a [dropdown field](/reference/fields/dropdown), and the lists those rules point at are usually plain simple picklists you already have.

## Static or automatic: the source axis

Everything above is shape. Where the options come from is an independent choice: a picklist is **static** (you maintain the options) or **automatic** (Terminus Hub derives them).

An automatic picklist points at a taxonomy you already maintain, say Campaigns, and at one field inside it. Whatever values that field holds across the taxonomy's **approved records** become the options. A Campaign dropdown therefore offers exactly the campaigns that already exist: approve a record and it appears in the dropdown, retire one and it leaves. People pick a real campaign instead of retyping an ID from a spreadsheet, and there is nothing to keep in sync by hand.

Two properties worth knowing:

* **It cascades too.** Define levels against the source taxonomy and the dropdowns narrow exactly like a linear cascade, with no level maintained by hand: pick `emea` and Campaign shows only approved EMEA campaigns.
* **Readable labels, clean values.** Records carry both a human name and a machine-safe code, so the dropdown can show `EMEA Summit 2026` while the governed value stays `emea-summit-2026`.

**How it is built:** in the picklist editor, but there is no grid to fill in. You choose the source taxonomy and the levels, and the options follow. See [automated picklists](/reference/picklists/automated) and the [automated picklist recipe](/recipes/automated-picklist).

## Which structure do I need?

Two questions per field. Start at the top, where most fields belong, and move down only when the row above cannot express what you need.

| Ask, about the shape                                                                 | If yes                |
| ------------------------------------------------------------------------------------ | --------------------- |
| Does the list stand on its own, with no dependency on another field's answer?        | **Simple**            |
| Does each answer narrow exactly one next question, getting more specific each step?  | **Linear cascade**    |
| Does one earlier answer change the valid values of several unrelated fields at once? | **Branching cascade** |
| Do different situations need a genuinely different list, not just fewer options?     | **Conditional**       |

| Ask, about the source                                                                      | If yes        |
| ------------------------------------------------------------------------------------------ | ------------- |
| Is this a vocabulary your team decides on and rarely changes?                              | **Static**    |
| Do these values already exist as another taxonomy's records, or as IDs Terminus generated? | **Automatic** |

You will end up using several of them. A mature taxonomy runs static simple lists for Medium and Region, a static cascade for Channel to Source to Placement, automatic for Campaign, conditional where a market has its own inventory, and branching only where one decision reshapes the form. Start simple, and promote a field the moment you catch the first invalid combination in reporting.

## Filtering a shared picklist

One canonical picklist can be reused everywhere and narrowed at each point of use. That is filtering, not structure: the list stays single, and what changes is which slice applies. There are two reasons to filter, and they are worth keeping apart.

* **Taxonomy filtering is structural.** A display taxonomy and a social taxonomy can draw on the same `Channel` picklist, each narrowed to the values that belong in that kind of campaign. The filter changes when the taxonomy changes. See the [filter options per taxonomy recipe](/recipes/filter-options-per-taxonomy).
* **Workspace filtering is operational.** Same mechanism, different motive: scoping a team to the values it may use. A local team's workspace shows only `fr` and `de` on the Region picklist while the global team sees all of it. Nothing about the taxonomy changed; access did.

And one convenience that falls out of filtering: **when narrowing leaves exactly one legal value, it is selected automatically**. That is what makes an inverted taxonomy pleasant to fill: choose the city, and country and region fill themselves in.

## Vocabulary note

The reference section names picklists by how they are stored: [static](/reference/picklists/static) (simple or cascading, hand-authored), [hierarchical](/reference/picklists/hierarchical) (a static picklist linked to a parent, which is how cascades are built), and [automated](/reference/picklists/automated) (the automatic source). Structure and source are the two decisions; those pages are the mechanics.

## Related

* [Picklists reference](/reference/picklists)
* [Dropdown field](/reference/fields/dropdown): conditional rules live on the field.
* [Cascading dropdowns recipe](/recipes/cascading-dropdowns)
* [Data model](/concepts/data-model): where picklists sit in the hierarchy.