Jira Cascading Select & Dependent Dropdowns: Filter Options by Another Field
Pick Hardware in a Category dropdown, and Jira happily offers Software license in the Subcategory list right below it. Jira's built-in answer is the cascading select — a custom field that bundles exactly two levels into one field and cannot react to anything else on the form. This guide covers what the native cascading select can and cannot do, and how to build true dependent dropdowns in Jira Cloud — one field's value filtering another field's options — without scripts.
Dependent dropdowns are one piece of building dynamic forms in Jira — forms whose fields and options react to context.
TL;DR
Jira's native Select List (cascading) custom field gives you two levels inside a single field — and that is where it stops: no third level, no reaction to other fields, no system fields, company-managed projects only. Dependent dropdowns keep parent and child as separate fields and filter the child's options with a rule: when Category is Hardware, Subcategory shows only hardware options. You can script that with ScriptRunner Behaviours, or build it no-code with Formify. Jump to the step-by-step setup.
What is a cascading select in Jira?
A cascading select is a Jira custom field type — Select List (cascading) — that holds two connected dropdowns in a single field: a parent list, and a child list whose options change based on the selected parent. Choose Hardware and the second list shows hardware options; choose Software and it swaps.
You create one in Settings → Issues → Custom fields in a company-managed project, then define the child options under each parent option in the field's context configuration. In JQL, the pair is queried with the cascadeOption() function:
"Category (cascading)" in cascadeOption("Hardware", "Laptop")
For a fixed two-level taxonomy that lives comfortably in one field, it does the job. The limits show up fast:
- Two levels, hard stop. There is no third list — a Category → Subcategory → Item chain is impossible inside the field.
- One field holds both values. Boards, dashboards, and exports see a single field; every query about a child value goes through
cascadeOption(). - The child follows only its own parent. The field cannot react to Issue Type, Priority, a request type, or any other field on the form.
- System fields are out. The cascade lives inside that one custom field — you cannot make Priority, Resolution, or a version field cascade.
- Company-managed only. Team-managed projects do not offer the field type at all.
Cascading select vs true dependent dropdowns
A cascading select bundles parent and child into one custom field. Dependent dropdowns are separate fields — Category and Subcategory each exist in their own right — with a rule that filters the child field's options based on the parent field's value.
Separate fields age better. Each level is queryable directly (Subcategory = "Laptop" — no function required), each can drive boards, dashboards, and automation on its own, and the dependency can key off any field — including fields you did not create, like Issue Type or Priority. The child does not have to be custom either: Priority, Resolution, Issue Type, Fix Versions, and Affects Versions can all be filtered.
| Capability | Native cascading select | Dependent dropdowns (rules) |
|---|---|---|
| Levels | Exactly 2, inside one field | Any number — chain separate fields |
| Reacts to other fields | No — the child follows its own parent only | Yes — any field's value can drive the filter |
| Works on system fields | No — custom field only | Yes — Priority, Resolution, Issue Type, Fix/Affects Versions |
| JQL & reporting | One field, cascadeOption() | Plain field = value per level |
| Team-managed projects | Not available | Yes |
| Setup | Field context configuration | One filtering rule per parent value |
The native field is fine when the two levels form a closed taxonomy nobody reports on separately. The moment someone asks "show me every issue with Office = Berlin, regardless of Region" — or you want the Priority list itself to shrink — you want separate fields with dependency rules.
How to build dependent dropdowns in Jira (step by step)
The pattern: keep parent and child as two regular select fields, and add one rule per parent value — a condition on the parent field, and a Limit Field Options action on the child.
Create the two fields as plain selects
Two Select List (single choice) custom fields — Category and Subcategory. Subcategory holds the full option list across all parents; the rules decide which slice is visible. Add both fields to your create screen. Existing fields work just as well — nothing about them needs to be special.
Install Formify from the Marketplace
Add Formify - Dynamic Fields for Jira from the Atlassian Marketplace. It installs as a Jira Cloud app — no scripts, no external setup.
Add a filtering rule for the first parent value
On the Global Issue Create screen, define a condition on the parent and a Limit Field Options action on the child. Option names must match the field configuration exactly.
Test cases
Repeat for each parent value
One rule per parent option keeps the mapping explicit and easy to audit. Adding a new Category later means adding one new rule — the rest stay untouched.
Test cases
Test on a real create dialog
Open the create dialog and flip Category back and forth. The Subcategory list swaps live as the parent changes — no page reload, no script console. If an option is missing, check the rule's option names against the field configuration; they are matched exactly.
Where the rules run — and where they don't
Option filtering runs on the create dialog and on transition dialogs — Jira does not support filtering options during inline edit on the issue view. Treat the create screen as the guarded entry point, and add the same rule on a transition where the pair gets revisited later. Values already saved on an issue are never removed: rules only limit what can be newly selected.
Dependent dropdown examples
Region → Office
One Office field for all of HR reporting. Region = EMEA shows Berlin, London, Warsaw; AMER shows Austin and Toronto. And Office = Berlin just works in JQL — no cascadeOption() gymnastics.
Product → Affected version
The child does not have to be custom. Filter Affects Versions so each product line exposes only its own release train — bugs stop landing on versions from the wrong product.
Issue type → Subcategory
The parent does not have to be a dropdown you created. Filter a child list by Issue Type, Request Type, or Priority — useful when Bugs and Service Requests share a field but not its options.
Filtering a child list is the same Limit Field Options action used to trim Priority or Resolution by context — see how to limit dropdown options for those recipes, and the Limiting Options docs for every supported field type.
Dependent dropdowns without ScriptRunner
For years, "make this dropdown depend on that field" in Jira meant ScriptRunner Behaviours: a Groovy script listens to the parent field and rewrites the child's options. It is still the most programmable route — but every dependency is code that a Jira admin owns, reviews, and debugs.
The no-code route expresses the same dependency as configuration: a condition on the parent, a Limit Field Options action on the child, one rule per parent value. There is nothing to deploy and nothing to debug at runtime.
| Approach | Cross-field dependency | Levels | Setup | Maintenance |
|---|---|---|---|---|
| Native cascading select | No | 2 | Field context configuration | Edit options per context |
| ScriptRunner Behaviours | Yes | Any | Groovy scripts | Code ownership |
| Formify rules | Yes | Any — chain rules across fields | No-code rule builder | Edit rules in a UI |
For the broader decision framework — native vs scripting vs no-code across all conditional-field needs, not just dropdowns — see native vs ScriptRunner vs no-code apps.
Build dependent dropdowns in 10 minutes
Two select fields, one rule per parent value — Formify filters the child's options live on the create screen. Free trial on the Atlassian Marketplace.
Start free trial on MarketplaceFAQ
Does Jira have dependent dropdowns natively?
Only inside the two-level cascading select custom field, where the child list follows the parent list in the same field. Jira has no native way to make one field's options depend on a different field — for that you need ScriptRunner Behaviours or a no-code app like Formify.
How do I add a cascading select field in Jira Cloud?
In a company-managed project, go to Settings → Issues → Custom fields and create a field of type Select List (cascading). Define the parent options and their child options in the field's context configuration, then add the field to your screens.
Can a Jira cascading select have three levels?
No. The native field supports exactly two levels — one parent and one child. For three or more levels, use separate select fields chained with filtering rules: Category filters Subcategory, and Subcategory filters Item.
How do I query a cascading select in JQL?
Use the cascadeOption() function: "Category (cascading)" in cascadeOption("Hardware") matches any child under Hardware, and cascadeOption("Hardware", "Laptop") matches the exact pair. With separate dependent fields you skip the function entirely and write Subcategory = Laptop.
Do cascading selects work in team-managed projects?
No — Select List (cascading) is a company-managed custom field type; team-managed projects do not offer it. The dependent-dropdown pattern is not tied to that field type, and Formify's filtering rules work in team-managed projects too.
Can one field filter another field's options in Jira?
Not natively. With a rule-based app, yes: a condition reads the parent field's value and a Limit Field Options action filters the child's list — live on the create and transition dialogs as the user changes the parent.
What happens to values that are no longer in the filtered list?
They stay. Filtering rules only limit what can be newly selected — a value already saved on an issue is preserved even if the current rules would no longer offer it. Nothing is deleted behind users' backs.
Do dependent dropdowns work on Jira Service Management request forms?
Yes. Option filtering applies to JSM request forms the same way as to standard create screens, so a portal field can show only the options that match the request type or another field's value.
Make one Jira dropdown depend on another
Formify filters a field's options by another field's value — no Groovy, no workarounds, works in team-managed projects. Free trial on the Atlassian Marketplace.
Start free trial on Marketplace