Related Custom Fields – Support Portal

Purpose: This article explains how to make one select-list custom field depend on another, so that choosing a value in the first narrows the options offered in the second.

Related custom fields (also called custom field dependencies) link two select lists as a parent and a child. For example, a Model field can depend on a Make field: when someone picks Make = BMW on a record, Model only offers BMW models. Fields can be chained, so a Trim field can depend on Model in turn: Make → Model → Trim.

This article explains:

Which fields can be linked
Setting up and removing a dependency
Seeing how your fields connect
What you can and can't change on a linked field
How related fields behave when users fill in a record
How the rules apply to the API and data imports

Which fields can be linked

Only single-choice select lists with custom options can depend on another field, or be depended on. Other field types show "Only select lists with custom options can depend on another field." in place of the dependency settings.

A parent field must also:

be a single-choice select list, not a multiple-choice one;
use options you have entered yourself, not a built-in option set such as Country or Language;
be used on every record type the child is used on. If Model is on Accounts and Contacts, Make must be on both too;
not already depend on the child, directly or through another field, as that would create a loop.

Fields that can't be a parent are greyed out in the Depends on dropdown, with the reason shown underneath.

The Depends on dropdown, with unsuitable fields greyed out and the reason for each

Set up a dependency

Create both fields first, with all of their options. Then set up the link on the child field:

Go to Control Panel → Custom Fields and open the child field (for example, Model).
In the Dependency section, choose the parent field (for example, Make) in Depends on.
A row appears for each of the parent's values ("When Make is"). For each one, choose the options the child should offer ("Model offers").
Click Save.

A parent value with nothing selected offers no options. If BMW has no Model options chosen, a user who picks BMW can't choose a Model at all. You can't save a dependency with nothing selected for any parent value: the modal asks you to "Choose options for at least one Make value, or set Depends on to None."

Setting up a dependency: choosing Make in Depends on, then the Model options for each Make, and saving

The same child option can be offered for more than one parent value. To build a chain, set up each link on its own child field: Model depends on Make, then Trim depends on Model.

The Dependency section of a field's Edit modal, showing the Model options offered for each Make

If a field has been linked to a parent through the API without any rules, the Dependency section explains that all of its options are offered until you choose options for at least one parent value.

Remove a dependency

Open the child field, set Depends on back to None and click Save. The link and its rules are removed, and the field offers all of its options again. Values already stored on records are not changed.

See how fields connect

In the Custom Fields list, a field that depends on another shows "Depends on" and the parent's name under its own name, for example "Depends on Make".
Opening a field that other fields depend on shows a Dependent fields section listing them, as a reminder that its options used in their rules can't be renamed or removed and that it can't be deleted until they are unlinked.

The Dependent fields section on the Make field

Changing or deleting linked fields

Some changes are blocked while fields are linked, so that existing rules keep working:

Deleting a parent field. A field that other fields depend on can't be deleted. The delete dialog lists the dependent fields instead; click a field's name to open it, set its Depends on to None and save, then delete the parent.
Renaming or removing a parent option. If a rule uses an option of the parent field (for example, BMW), that option can't be renamed or removed. Remove the rule on the child field first, by clearing the options chosen for that value.
Removing the parent from a record type. A parent must stay on every record type its child is used on. Remove the child from that record type first.
Removing a child option is allowed. Rules that offered it are tidied up the next time the child field is saved.

The Can't delete dialog, listing Model as a field that depends on Make

Filling in records

Related fields work the same way on every record type that uses them, such as Accounts, Contacts and Course Templates:

Pick the parent first. The child only offers the options allowed for the parent's current value. While the parent is empty, or if the chosen value has no options set up, the child shows "No options".
Changing the parent clears the child, and any fields further down the chain. Picking a different Make clears both Model and Trim.
Values the rules no longer allow are flagged. If the rules change after a value was saved, the field is flagged when the record is next edited, listing the choices that are now allowed. Choose a new value before saving.

On an account, picking Make = BMW narrows Model to BMW models, then changing Make to Audi clears Model and Trim

Users can only fill in a child field if they can see its parent. If a role has no access to the parent field, users with that role can't set the child either. See Custom Field permissions.

API and data imports

The rules apply however a value is written. The API and the Data Import tool reject any combination the rules don't allow, and the error lists the values that are allowed.

When a write only sets the child field, the parent value already stored on the record is used to check it. To change both, send the parent and child values together.

For more on setting up custom fields, see Custom Fields.

On this page