Skip to main content
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.

​
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.

​
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

1

Open the new-picklist flow

Open the Marketing model, go to Picklists, and create a new picklist. Choose the Static type.
2

Name it Goals

Name: Goals. Leave it flat (no parent picklist). Save.
3

Add the three options

Add three options, each with a code and a label:
CodeLabel
awarenessAwareness
considerationConsideration
conversionConversion
Save. All three options now appear in the picklist, in the order you entered them.
4

Create the goal Dropdown field

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.

​
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. Build Countries and Regions so picking a country cascades the region dropdown. For all of a picklist’s options, see the picklists reference and the static picklist reference.