Field Dependencies in Salesforce
One controlling field, one dependent picklist, and a matrix that decides which values a user actually sees. Here’s exactly how the relationship works — and where it stops.
A field dependency in Salesforce filters the values shown in a dependent picklist based on the value chosen in a controlling field on the same record. The controlling field can be any picklist (with fewer than 300 values) or a checkbox; the dependent field must be a custom picklist. It’s a user-interface filter — not a validation rule, and not enforced on data loads.
How field dependencies in Salesforce work
A field dependency links two fields on the same object: a controlling field and a dependent picklist. When a user selects a value in the controlling field, Salesforce narrows the dependent picklist to only the values you’ve mapped to that selection. The classic example is geography — set Country as the controlling field and State as the dependent field, and choosing “United States” shows only US states instead of every region worldwide.
You build the mapping in the field dependency matrix. The top row lists the controlling field’s values and the columns list the dependent field’s values; you include or exclude each combination. An included value appears in the dependent picklist when its controlling value is selected — an excluded one doesn’t. To create one, go to Setup → Object Manager → [Object] → Fields & Relationships → Field Dependencies → New, pick the two fields, and fill in the matrix. Defining dependencies requires the Customize Application permission, and the feature is available in every edition, in both Lightning Experience and Salesforce Classic.
Dependencies can also chain. A dependent picklist can itself act as the controlling field for a third picklist, letting you build multi-level cascades (for example, Region → Country → State). Field dependencies are one field-configuration tool within Salesforce’s broader data model — for the wider picture of objects, fields, and relationships, they sit alongside the concepts covered in our data modeling pillar.
Both fields must live on the same object and apply to the same record. A field dependency can’t reach across objects — if you need a value on a related record to drive a picklist, that’s a job for a formula field, a flow, or Apex, not a dependency.
Which fields can be controlling vs dependent
The two roles have different, non-interchangeable rules. Getting them straight is where most of the exam traps live.
Controlling field
- Any picklist with at least one and fewer than 300 values
- Or a checkbox (its two states drive the dependent values)
- Can be a standard or custom field
- Can have a default value set
- A multi-select picklist can not be a controlling field
Dependent field
- Must be a custom picklist (single-select)
- Or a custom multi-select picklist
- A checkbox can never be a dependent field
- You can not set a default value on it
- Can itself control a further picklist (multi-level)
Two asymmetries are worth memorizing. A checkbox can be a controlling field but never a dependent one. A multi-select picklist is the opposite — it can be a dependent field but never a controlling one. Converting an existing field into a controlling or dependent field doesn’t change values already saved on records; the dependency rules apply only to new records and to future edits of existing ones.
Field dependencies and record types
Field dependencies and record types both filter picklist values, and on the same record they work together rather than in isolation. The record type controls which values are available in the controlling field in the first place. Then the record type and the selected controlling value jointly determine what the user sees in the dependent picklist: a dependent value appears only if it is available in the selected record type and mapped to the chosen controlling value.
Because of that interaction, confirm your controlling and dependent values are assigned to the right record types before you build the dependency — otherwise a value can silently disappear even though the matrix includes it. If record types are new to you, start with the full guide to record types in Salesforce and how they filter picklist values, then layer dependencies on top.
What field dependencies don’t do
A field dependency is a UI filter, and its limits matter as much as its behavior. It narrows what a user can pick on screen — it does not validate data that arrives any other way.
Import wizards and the API do not honor field dependencies. Any value can be written to a dependent picklist regardless of the controlling field’s value. If a record is created through Data Loader, an API integration, or an import, an “invalid” controlling/dependent combination will save without error.
When the controlling/dependent combination truly must be enforced — not just guided — back the dependency with a validation rule. The dependency keeps the UI clean; the validation rule blocks bad combinations from any entry path, including imports and integrations.
A few more boundaries: field-level security for the controlling field and the dependent picklist is set independently, so remember to hide the controlling field wherever its dependent picklist is hidden — otherwise users see a control with no visible effect. And for lead conversion, if you map dependent lead fields to account, contact, or opportunity fields, recreate the same dependency on those objects, since the mapping doesn’t carry the rule across.
Exam-Ready Recap
- Roles are fixed: controlling field = any picklist (<300 values) or checkbox; dependent field = custom single- or multi-select picklist. Same object only.
- The two asymmetries: a checkbox can control but never depend; a multi-select can depend but never control.
- Not enforced on load: imports and the API ignore dependencies — pair with a validation rule to actually block bad combinations.
- Record types stack: a dependent value shows only if it’s in the selected record type and mapped to the chosen controlling value.
Test your knowledge
Field dependencies, picklists, and data-model design show up across the App Builder blueprint. Drill them with scenario questions.
Verified against the official Salesforce Summer ’26 documentation — Dependent Picklists, Define a Dependent Picklist, and the Dependent Picklist Considerations Help topics, plus the Trailhead Picklist Administration module. Study smarter at CertifySF.com.