> ## 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.
# Part 4: Static picklists
> Build the Goals static picklist and a goal Dropdown field, and learn how an option's code and its label differ and why the code is what matters.
**What you'll learn:** how picklists supply dropdown options, how an option's code differs from its label, and why the code is what matters.
**What you'll build:** the `Goals` static picklist with three options, plus a `goal` Dropdown field that uses it.
**Prerequisites:** [Part 3: Fields basics](/tutorial/03-fields-basics).
## Why this matters
Dropdowns are how you keep data clean. Free text for "goal" would give you `awareness`, `Awareness`, `awarness` (a typo), `brand awareness`, and several other variants within a week, none of them comparable. A picklist locks the allowed values to exactly what you choose, and it keeps the stored value (the **code**) separate from the label a user sees. That is what makes `utm_campaign` assembly in Part 7 predictable: when the model splices in `goal`, it gets `awareness`, every time.
## Concepts first
### Picklist
A **picklist** is a reusable list of options that powers one or more Dropdown fields. You define the picklist once on the model, then point any number of Dropdown fields at it. In this tutorial every dropdown (`goal`, `country`, `region`, `utm_medium`, `utm_source`) is backed by a picklist.
### Code versus label
Every picklist option has two parts:
* **Code**: the stored value (1 to 100 characters). This is what ends up in records and what computed fields read.
* **Label**: the human-readable description shown in the dropdown.
Codes should be stable: lowercase, `snake_case`, no spaces, no punctuation. Labels can be anything. For `Goals`, the code `awareness` carries the label `Awareness`, and the code `conversion` carries the label `Conversion`. People pick by label; the system stores the code. Each option also has a position that sets its order in the list.
### Static picklist
A **static** picklist is one an admin fills in by hand. The options do not come from anywhere else: you type them, and they stay what you typed. This is the default kind, and the right choice when the list is small and stable. The other kind, an **automated** picklist, sources its options live from another taxonomy's records; that is covered in a [separate recipe](/recipes/automated-picklist).
### Why dropdowns need a picklist
Every Dropdown field points at exactly one picklist. There is no Dropdown with no picklist, and there are no per-field inline options, because the options always live in a named picklist the field references. That is what lets one list power several fields and lets you add an option in one place. You can still create the list without leaving the field editor: when you add a Dropdown field, you can build a new flat list inline, and it is saved as a named picklist you could reuse elsewhere.
## Step by step
Open the `Marketing` model, go to **Picklists**, and create a new picklist. Choose the **Static** type.
Name: `Goals`. Leave it flat (no parent picklist). Save.
Add three options, each with a code and a label:
| Code | Label |
| --------------- | ------------- |
| `awareness` | Awareness |
| `consideration` | Consideration |
| `conversion` | Conversion |
Save. All three options now appear in the picklist, in the order you entered them.
Go back to **Fields** and create a new field. Name: `goal`. Type: **Dropdown**. For the picklist, select `Goals`. Save. The `goal` field appears in the field list alongside the three fields from Part 3.
Screenshot coming soon: Part 4 Goals picklist.
## Check your work
* A picklist named `Goals` exists on the `Marketing` model with exactly three options: `awareness` / Awareness, `consideration` / Consideration, `conversion` / Conversion.
* A field named `goal` exists, is of type Dropdown, and references the `Goals` picklist.
* The model now has four fields total: `campaign_name`, `launch_date`, `destination_url`, `goal`.
## What you just built
The first dropdown in the system. When a submitter eventually opens a campaign form, `goal` renders as a three-item picker. When they choose "Awareness," the value stored is `awareness`. That code is what Part 7's `utm_campaign` field splices into the URL.
```mermaid theme={null}
flowchart LR
PL[Goals picklist
awareness / Awareness
consideration / Consideration
conversion / Conversion] --> F[goal field
Dropdown]
```
## Gotchas
* **Codes are what gets stored, so choose them carefully the first time.** If you change `awareness` to `awareness_v2` later, records created earlier still reference the old code, which no longer exists in the list. Labels are safe to edit; codes are not.
* **A static picklist needs at least one option** unless you turn on new values (covered in Part 6). You cannot save an empty `Goals` list.
* **Picklist names are unique within a model.** You cannot have two `Goals` picklists on `Marketing`. You could have a `Goals` on `Marketing` and another `Goals` on a different model, because they are different models.
* **Option codes must be unique within the list.** Two options cannot both use the code `awareness`. (In Part 5 you will see the one exception: the same code can repeat under different parents in a hierarchy.)
* **Point a dropdown at a different picklist with care.** If records already exist, swapping the field to a different list can leave those records referencing options the new list does not contain. To change the choices, add options to the existing list instead.
## Next up
[Part 5: Hierarchical picklists](/tutorial/05-hierarchical-picklists). Build `Countries` and `Regions` so picking a country cascades the region dropdown. For all of a picklist's options, see the [picklists reference](/reference/picklists) and the [static picklist reference](/reference/picklists/static).