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 utm_campaign 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 governance 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. Publishing a governance model that contains an automated picklist requires the Business plan or higher (see Plans and limits); this tutorial uses static picklists only.

​
Why dropdowns need a picklist

Every Dropdown field points at a 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

With the Marketing governance model open, click Picklists in the sidebar, then Create new, and choose Static Picklist. The editor opens as a grid with Code and Label columns under a single column header that reads Name.
2

Name it Goals

The column header is the picklist’s name. Click Name in the header (its tooltip reads Rename level), type Goals, and press Enter. Leave it as a single level; you add levels in Part 5.
3

Add the three options

Type each option into its own row, a code and a label. The grid always keeps an empty row at the bottom for the next option:Click Save. Goals now appears in the Picklists list with its three options, in the order you entered them.
4

Create the Goal Dropdown field

Click Fields in the sidebar, then Create new, and pick Dropdown. Name: Goal. In Picklist, select Goals. Click Save to draft. 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 governance 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 governance 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. You cannot save an empty Goals list; the editor asks you to add at least one option first.
  • Picklist names are unique within a governance model. You cannot have two Goals picklists on Marketing. You could have a Goals on Marketing and another Goals on a different governance model.
  • 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.