Building nested drop-down lists

Nested drop-downs turn one long list into a short choice followed by a shorter one. They are built entirely in the value names.

Nested drop-downs turn one long list into a short choice followed by a shorter one. They are built entirely in the value names.

Build a nested list

1. Edit the drop-down field.
2. Write each value with two colons between the levels: Hardware::Laptop, Hardware::Printer, Software::Licence.
3. Save.

The last part is what shows on the ticket once somebody has chosen: with Hardware::Laptop the field reads Laptop, and the category is how they got there rather than what is recorded.

Zendesk builds the hierarchy from the names, so there is no separate parent to create. Three limits apply: up to 66 levels of organisation, up to 2,000 values in one drop-down list, and at most 255 characters per field. The second is the one a large catalogue meets first, because every leaf of the tree is a value of its own.

What the agent sees

A first choice showing only the top level, then a second showing only the children of what they picked. Forty options become two choices from six.

The tag catch

Each value has a tag attached, and by default the tag is derived from the full path. Renaming a parent therefore changes the tags of every child, and any rule or report keyed on those tags stops matching.

Setting the tags explicitly, rather than accepting the generated ones, avoids that entirely. It costs a few minutes at build time and saves an afternoon later.

Reporting on a nested field

Explore sees the full value, so a report groups by "Hardware::Laptop" rather than by "Hardware". Reporting on the top level alone needs a calculated attribute that takes the part before the colons. Check this before you promise someone a breakdown by category.

See also

• The field types and when to pick which
• What tags are and what you use them for
• Creating a standard calculated attribute
• Importing and exporting fields and values