The pattern: confirm both Controlling and Dependent fields exist as picklists, create the dependency, map the matrix with Include All as starting point, pair with Validation Rule for API-level enforcement. The setup is straightforward; the discipline is in the validation rule pairing.
- Create the Controlling and Dependent picklists first
Both fields must exist before the dependency can be created. Build the picklists with their full value sets.
- Open Field Dependencies for the object
Object Manager, pick the object, Fields and Relationships, Field Dependencies. Click New.
- Pick Controlling and Dependent fields
Controlling is the field whose value drives the dependency. Dependent is the field whose available values change based on Controlling.
- Use Include All to start the matrix
Enable every combination as the starting point. Then disable invalid cells. Faster than enabling cells one at a time for large picklists.
- Save and test in the UI
Open a record, pick a Controlling value, confirm the Dependent picklist refreshes correctly. Test multiple Controlling values.
- Add a Validation Rule for API enforcement
Field Dependencies enforce only in the UI. A Validation Rule that asserts the same constraint at the platform level holds the dependency across Data Loader and API.
- Document the dependency rationale
The matrix is not self-explanatory. Document the intent in object documentation so future admins understand why specific combinations are disabled.
Picklist or checkbox whose value drives the Dependent Field's available values.
Picklist whose available values are constrained by the Controlling Field.
Per-cell configuration of which (Controlling, Dependent) pairs are valid.
Platform-level enforcement complementing the UI-level dependency. Required for API-entry integrity.
Dependent fields can themselves control deeper Dependent fields. Adds matrix complexity per level.
- Field Dependencies enforce in the UI only. Data Loader and API bypass them; pair with a Validation Rule for full integrity.
- The matrix starts empty by default. Without Include All, no Dependent values appear; admins regularly miss this on first setup.
- Multi-level dependencies multiply matrix configuration burden. Cap at two levels unless genuinely required.
- Record Type restrictions and Field Dependencies layer together. Reason about combined behavior carefully; document the intent.
- Very large picklists make the matrix unwieldy. Consider lookup relationships for value sets past a few hundred per axis.