FAQs: Nested picklist fields | Zoho Desk

FAQs: Nested picklist fields

Understanding nested picklists

What is a nested picklist field?
A nested picklist is a parent-and-child picklist configuration in which the options shown in one field depend on the value selected in another field. The parent field controls which child values are relevant and available.

For example, an administrator can configure Product Type as the parent field and Issue Type as the child field. If a customer selects “Hardware,” the Issue Type field can show options such as “Installation,” “Damaged Item,” and “Replacement.” If they select “Software,” it can instead show “Login,” “Configuration,” and “Integration.”
Why should nested picklists be used instead of one large picklist?
Nested picklists reduce irrelevant choices and help users submit more accurate data. Rather than asking users to search through a long list of unrelated options, the child field presents only the choices that apply to their parent selection.

This is particularly useful when one broad category contains multiple specialized subcategories, such as country and state, product family and product model, or service area and request type.
Are nested picklists the same as field dependencies?
Nested picklists use field dependencies: a parent picklist value determines the available values in a child picklist field. The relationship is configured by mapping each parent value to one or more child values.

The fields involved must be Pick List data type fields. When a record is created, the child field is populated according to the value selected in the parent field.
Which types of fields can be used as parent and child fields?
Nested relationships are created using Pick List data type fields. A parent field and child field must be available in the selected module and department before the dependency can be mapped.

For example, a Tickets layout can use a Category picklist as the parent and a Subcategory picklist as the child.
Can a nested picklist be color coded?
No, Picklist values in a nested picklist cannot be color coded. A field that already has nested picklist behavior also cannot be converted into a color-coded picklist.

If both visual prioritization and dependent selection are needed, use separate fields. For instance, use a nested Category/Subcategory pair for classification and a separate color-coded Severity field for urgency.

Creating the dependency

How can a nested picklist relationship be created?
  1. Navigate to Setup > Customization > Layouts and Fields.
  2. Select Fields Dependencies from the Layouts and Fields submenu.
  3. Choose the applicable:
    1. Module
    2. Department
  4. Click Add New Dependency.
  5. In the Add New Dependency window:
    1. Select the Parent Field.
    2. Select the Child Field.
  6. Click Next.
  7. Map the field values:
    1. Select a parent-field value.
    2. Choose the child-field values that should be available when that parent value is selected.
    3. Repeat the mapping for each parent value.
  8. Click Save Field Dependency.
After saving, the child picklist responds to the value chosen in the parent picklist when users create a new record.
Can one parent picklist value be associated with multiple child values?
Yes. Each parent value can be mapped to multiple relevant child values.

For example, the parent value Billing can reveal child values such as “Invoice Copy,” “Payment Failed,” “Refund Request,” and “Tax Details.” This gives users enough specificity without exposing issue types that belong to unrelated categories.
Can the same child value be used under more than one parent value?
The available configuration maps child options to parent values. Where a child option is relevant for multiple parent categories, it can be selected for each applicable parent-value mapping.

For example, “Other” may be relevant under both “Hardware” and “Software,” while “Device Not Powering On” should be mapped only to “Hardware.”
What happens when a user changes the parent picklist value?
The child field is driven by the parent selection. When the parent value changes, users should select an appropriate child option from the choices mapped to the newly selected parent value.

Administrators should therefore avoid mappings that create ambiguity. For example, if “Account Access” belongs to both “Billing” and “Technical Support,” consider whether a more specific child label would improve reporting and assignment accuracy.

Record Entry and User Experience

What will users see when they create a record with nested picklists?
Users first select a value in the parent picklist. The child picklist then presents the values mapped to that parent choice.

For example:
  1. Parent field: Service Area
  2. Selected value: Delivery
  3. Child field: Delivery Issue
  4. Available child values: Delayed Shipment, Incorrect Address, Missing Package, Tracking Request
This prevents users from choosing unrelated values such as “Password Reset” under a delivery-related request.
Can nested picklists be used to improve ticket routing and reporting?
Yes. Nested picklists create more consistent categorization because users select from context-specific child options. This can make it easier to identify trends and distinguish similar-looking requests.

For example, “Payment Failed” can be reported as a Billing issue, while “Login Failed” is reported as an Account Access issue. The parent category gives the high-level grouping, and the child value adds the operational detail needed for review or assignment.


Do field permissions still apply to nested picklists?
Yes. Field permissions determine whether a user can view or edit fields. A nested picklist relationship controls which child values are relevant after a parent value is selected; it does not replace the field-level access settings.

If a user cannot view a field because it is configured as Don’t Show, the dependency does not make that field visible. Similarly, a read-only field remains read-only.

Administration and Maintenance

What should be checked before creating a dependency?
Confirm the following before configuring a nested picklist:
  1. Both parent and child fields are Pick List fields.
  2. The fields are available in the intended module and department.
  3. Parent values have clear, mutually understandable meanings.
  4. Child values are mapped only where they are relevant.
  5. Field permissions and layout placement allow intended users to access the fields.
A well-planned structure avoids duplicate values and inconsistent selections later.
How should parent and child values be designed for clear reporting?
Use the parent field for the broad classification and the child field for the specific reason or subtype. Avoid using two fields that repeat the same level of detail.

For example:
  1. Effective: Category → Billing; Subcategory → Refund Request
  2. Less effective: Category → Refund; Subcategory → Refund Issue
The first approach gives a clear hierarchy that makes ticket analysis more meaningful.
Can field dependencies be used across all modules?
Field dependencies are configured by selecting a specific module and department. The dependency applies within that selected context, provided the relevant picklist fields are available there.

If the same classification is needed in another module or department, review and configure the dependency in that applicable context rather than assuming that a mapping automatically applies everywhere.
What should be done if users cannot find an expected child value?
Administrators should verify:
  1. The user selected the correct parent value.
  2. The required child value exists in the child picklist.
  3. The child value was mapped to that specific parent value.
  4. The correct module and department were selected when the dependency was configured.
  5. The relevant fields are visible and editable for the user’s profile.
For example, if “Refund Request” does not appear after selecting “Billing,” the mapping for the Billing parent value may need to be updated.
Can a nested picklist replace a layout rule?
Not always. A nested picklist controls the values shown in a child picklist according to a parent selection. Layout rules can control broader interface behavior, such as showing fields, sections, or making fields mandatory under specified conditions.

For example, a nested picklist can show “Refund Request” only under the “Billing” category. A layout rule can then show a Transaction ID field and make it mandatory when “Refund Request” is selected.