The short version: a dependent picklist limits its own values based on what is selected in a controlling field, and the whole feature lives in one matrix screen on the dependent field. It is enforced properly in the standard record UI and it is not enforced by the API, so anything loading data or writing through Apex can create combinations your matrix says are impossible. Plan for that rather than assuming the platform will stop it.
Setting one up
Go to the dependent field, not the controlling one. Object Manager, Fields and Relationships, open the field, then Field Dependencies. You pick the controlling field and get a grid: controlling values across the top, dependent values down the side. Double-click a cell to include or exclude that value for that controlling selection.
Two things about the grid catch people. Values are included per column, so a dependent value can appear under several controlling values, which is usually what you want for shared options. And a column with nothing included leaves a user facing a required field with no options. Check every column before saving.
The rules on what can control what
- A controlling field can be a custom picklist, a standard picklist, or a checkbox. A checkbox gives you two columns, true and false.
- A multi-select picklist can be dependent. It cannot be a controlling field.
- Standard picklists can control, but most standard picklists cannot themselves be made dependent.
- Record Type is not a controlling field. It filters the same list through a different mechanism, and both filters apply at once.
- A field can be dependent on only one controlling field. Chains are allowed, so A controls B and B controls C, but B cannot be controlled by both A and D.
That last combination is the request that arrives most often. Design around it by collapsing two controlling fields into one, or by moving the logic to a lookup.
Record types and dependencies together
Record types restrict which values of a picklist are available. Field dependencies restrict which values are available given a controlling selection. Both filters apply, and the platform takes the intersection.
The intersection can be empty. A record type that excludes the only dependent value valid for the selected controlling value leaves a required field offering nothing. Nothing warns you. Testing means walking each record type against each controlling value, which is tedious and is the only way to find it.
What happens in Flow
A picklist choice set on a Flow screen does not respect field dependencies. It shows every value of the dependent field regardless of what was chosen elsewhere on the screen, because it is reading the field definition, not the dependency matrix.
There is a dedicated dependent picklists screen component that does respect them, and it is the right answer when you need the behaviour on a screen. It works against a real object and its configured dependencies, so it will not help for choices that only exist inside the Flow.
What happens through the API
Data Loader, Bulk API, Apex and integrations write the dependent value without checking the matrix. A load that sets a controlling value of “Hardware” and a dependent value of “Consulting Hours” will succeed if both values exist on their respective fields.
Once such a record exists it is visible and reportable, and it becomes obvious only when a user opens it. The record page shows the invalid value as selected, and the moment the user touches the picklist that value disappears from the list, so saving forces a valid choice.
If the combination genuinely must never exist, write a validation rule as well as the dependency. The dependency is the user experience. The validation rule is the guarantee.
Deployment and translation
Field dependencies deploy as part of the dependent field’s metadata, so a change set or source deployment carries them along with the value set. Deploying a dependency to an org where a referenced value is missing fails the whole deployment, which is correct behaviour and a common change set surprise. Translations follow labels, not the matrix.
Frequently asked
Why do I see all values when editing from a list view? Inline edit in a list view and mass inline edit do not always show the controlling field, and where the controlling value is not in context the dependency cannot be applied. Treat list view editing as unreliable for dependent fields.
Can I use a global value set with a dependency? Yes. The value set defines the values. The dependency is configured on the individual field and is not shared across every field using that set.
What happens to existing records if I change the matrix? Nothing. Stored values are untouched, and records now holding an excluded combination stay as they are until someone edits the field.
