Limiting Dropdown Options
Limiting dropdown options shows only relevant choices in select fields based on context. Instead of overwhelming users with all possible options, rules filter dropdowns to show only valid selections—reducing errors and improving data quality.
Formify enables context-aware option filtering for cleaner, more intuitive forms.
Why Limiting Options Matters
Problem: Dropdowns show all possible options regardless of context. Users see irrelevant choices, leading to invalid selections and data cleanup later.
Solution: Filter dropdown options based on issue type, priority, the value of another dropdown, or other criteria. Users see only appropriate choices for their specific situation.
Benefits:
- Prevents invalid selections - irrelevant options aren't available
- Faster form completion - shorter dropdowns are easier to scan
- Better data quality - constrained choices eliminate incorrect values
- Clearer intent - available options guide users toward correct selections
Supported Field Types
The "Limit Field Options" action works with these field types:
System fields:
- Priority - Issue priority field
- Fix Versions - Fix Versions field, in transition dialogs only (Jira doesn't limit its options on Create or on the Issue View)
- Issue Type - Issue type field
Custom fields:
- Single Select - Custom select fields
- Radio Buttons - Custom radio button fields
- Multi-Select - Custom multi-select fields
- Checkboxes - Custom checkbox fields
On the Issue View, the action works on Priority and the four custom field types.
Other fields: The action isn't offered for other fields, such as Resolution, Components, Affects Versions, Parent, Request Type or cascading select fields. Text, date, number and user picker fields have no options to limit. Where you need a filtered list of choices, use a custom select list, for example "Closure Reason" instead of Resolution or "Area" instead of Components.
Basic Pattern: Show Only Specific Options
The simplest option limiting rule shows only certain values when conditions are met.
Example 1: Show Only High Priorities for Critical Bugs
Requirement: Bugs in critical infrastructure should only allow the two highest priorities
Rule Configuration:
- Screen: Global Issue Create
- Target Field: Priority
- Scope: Bug
- Condition: Area (select list) = Critical Infrastructure
- Action: Limit Field Options
- Options to show: High, Critical (hide all others)
User Experience:
- User creates Bug with Area = Critical Infrastructure
- Priority dropdown shows only "High" and "Critical"
- Lower priorities (Medium, Low) are not available
- Prevents accidentally marking critical bugs as low priority
Issue Type-Specific Options
Show different dropdown options for different issue types.
Example 2: Different Closure Reasons for Bugs vs Stories
Requirement: Bugs should have technical closure reasons; Stories should have completion-focused ones
Resolution can't have its options limited, so this example uses a custom select list, Closure Reason, kept on the Done transition's screen only. A Transition rule runs in every transition dialog whose screen shows the field, so no status condition is needed.
Rule 1: Bug Closure Reasons
- Screen: Issue Transition
- Target Field: Closure Reason (select list)
- Scope: Bug
- Condition: none
- Action: Limit Field Options
- Options to show: Fixed, Won't Fix, Duplicate, Cannot Reproduce
Rule 2: Story Closure Reasons
- Screen: Issue Transition
- Target Field: Closure Reason
- Scope: Story
- Condition: none
- Action: Limit Field Options
- Options to show: Completed, Declined
User Experience:
- Closing Bug → Closure Reason dropdown shows technical options
- Closing Story → Closure Reason dropdown shows completion options
- Each issue type has appropriate closure choices
Status-Based Option Filtering
Limit options based on workflow status to ensure valid transitions.
Example 3: Restrict Fix Versions on Done Transition
Requirement: When transitioning to Done, only allow released versions (not future versions)
Rule Configuration:
- Screen: Issue Transition
- Target Field: Fix Versions (on the Done transition's screen only)
- Scope: Bug, Story
- Condition: none: the field's place on the Done transition's screen limits the rule to that transition
- Action: Limit Field Options
- Options to show: Version 1.0, Version 2.0 (only released versions, hide unreleased)
User Experience:
- User transitions issue to Done
- Fix Versions dropdown on transition dialog shows only released versions
- Prevents marking done work for unreleased versions
The rule keeps the versions you picked: a version created or released later isn't added or removed automatically, so update the rule when you release or add a version.
Priority-Based Option Filtering
Show different options based on issue priority.
Example 4: Limited Teams for Low-Priority Issues
Requirement: Low-priority issues should only route to general support, not specialized teams
Rule Configuration:
- Screen: Global Issue Create
- Target Field: Support Team (select list)
- Scope: Support Ticket
- Condition: Priority = Low
- Action: Limit Field Options
- Options to show: General Support, Documentation (hide specialized teams)
User Experience:
- User creates Support Ticket with Priority = Low
- Support Team dropdown shows only general options
- High-priority tickets see all teams (no limiting rule)
- Routes low-priority work appropriately
User-Based Option Filtering
Show different options to different users based on role or group.
Example 5: Limited Priorities for Non-Managers
Requirement: Only managers can create Critical priority issues
Rule Configuration:
- Screen: Global Issue Create
- Target Field: Priority
- Scope: All issue types
- Condition: User NOT in group "Managers"
- Action: Limit Field Options
- Options to show: High, Medium, Low (hide Critical)
User Experience:
- Regular user creates issue → Priority dropdown excludes "Critical"
- Manager creates issue → All priorities available (rule doesn't apply)
- Prevents priority inflation; critical issues require manager approval
Multi-Condition Option Filtering
Combine multiple conditions for precise option control.
Example 6: Version Selection Based on Type and Priority
Requirement: When a high-priority Story is resolved, it should only target the current release; other priorities can target any version
Rule Configuration:
- Screen: Issue Transition (Fix Versions options can be limited only in transition dialogs)
- Target Field: Fix Versions (on the Done transition's screen, together with Priority: a Priority condition needs the field on the screen)
- Scope: Story
- Conditions:
- Priority = High OR Priority = Critical
- Action: Limit Field Options
- Options to show: Version 3.0 (current release only)
User Experience:
- User resolves a high-priority Story → Fix Versions in the transition dialog shows only the current release
- User resolves a medium/low-priority Story → All versions available
- High-priority work constrained to current release cycle
Dependent Dropdowns
A dependent dropdown offers only the options that fit the choice made in another dropdown: limit field B's options when field A equals X. Field A is a select list or radio buttons field, field B is a select list. Create one Limit Field Options rule on B for each value of A.
Example 7: Category and Subcategory
Requirement: Subcategory should offer only the subcategories of the selected Category
Rule 1: Hardware Subcategories
- Screen: Global Issue Create
- Target Field: Subcategory (select list)
- Scope: Support Ticket
- Condition: Category (select list) = Hardware
- Action: Limit Field Options
- Options to show: Laptop, Monitor, Peripherals
Rule 2: Software Subcategories
- Screen: Global Issue Create
- Target Field: Subcategory
- Scope: Support Ticket
- Condition: Category = Software
- Action: Limit Field Options
- Options to show: Installation, License, Bug
Rule 3: Access Subcategories
- Screen: Global Issue Create
- Target Field: Subcategory
- Scope: Support Ticket
- Condition: Category = Access
- Action: Limit Field Options
- Options to show: New Account, Password Reset, Permissions
User Experience:
- User picks Category = Hardware → Subcategory offers Laptop, Monitor, Peripherals
- User switches Category to Software → Subcategory changes at once to the software options
- No Category picked yet → no rule applies, so Subcategory shows all its options
How it behaves:
- Every screen where Limit Field Options runs: The same rules work on Global Issue Create, Issue Transition and Issue View; add them on each tab where you need them.
- A limited parent works too: If another rule limits Category's own options (for example, Bugs can't pick Access), the Subcategory rules still follow whichever Category the user picks.
- A picked value stays: Hiding options doesn't clear a value already selected. If the user picks Hardware and Laptop, then switches Category to Software, Laptop stays in Subcategory although it's no longer offered. The user should pick the subcategory again.
Practical Use Cases
Software Development Team
Limit priorities for different bug types:
- Scope: Bug
- Condition: Area (select list) = Documentation
- Action: Show only Low, Medium priorities
- Result: Documentation bugs can't be marked Critical
Restrict Fix Versions to the current release:
- Screen: Issue Transition (Fix Versions on the Done transition's screen; its options can't be limited on Create or on the Issue View)
- Scope: Story, Task
- Condition: none
- Action: Show options: 3.0 (the current release)
- Result: Stories and tasks are resolved into the current release; pick the next version in the rule when the release changes
Customer Support Team
Show only customer-facing closure reasons:
- Screen: Issue Transition (Closure Reason on the Resolve transition's screen only)
- Scope: Customer Request
- Condition: none
- Action: Show Resolved, Won't Fix in Closure Reason (select list), hide internal options
- Result: Customer-facing issues get appropriate closure reasons
Limit severity based on customer tier:
- Scope: Support Ticket
- Condition: Customer Tier (select list) = Free
- Action: Show Low, Medium severity only
- Result: Critical severity reserved for paying customers
Release Management
Show only unreleased versions while work is open:
- Screen: Issue Transition
- Condition: Issue is not in status Done, Closed
- Action: Show options in Fix Versions: 3.0, 3.1, 3.2 (the unreleased versions)
- Result: When open work moves through the workflow, Fix Versions offers only the picked future releases. On a transition, the status condition checks the status the work item is leaving.
Common Patterns
Pattern 1: Issue Type-Specific Options
Show different options for different issue types.
Scope: Bug
Action: Limit Priority to High, Medium, Low
Scope: Story
Action: Limit Priority to High, Medium
Pattern 2: Transition-Specific Options
Limit options in one transition's dialog. Keep the field on that transition's screen only; no status condition is needed.
Screen: Issue Transition
Field: Fix Versions, on the Done transition's screen only
Condition: none
Action: Limit Fix Versions to 1.0, 2.0 (the released versions)
Pattern 3: Priority-Based Routing
Show different teams based on priority.
Condition: Priority = Critical
Action: Limit Support Team (select list) to specialized teams
Condition: Priority = Low
Action: Limit Support Team to general support only
Pattern 4: Role-Based Options
Show different choices to different user groups.
Condition: User NOT in group "Managers"
Action: Limit Priority (hide Critical option)
Pattern 5: Scope Plus Condition
Combine the rule's work type scope with a condition for precise control. The scope always applies on top of the conditions.
Screen: Issue Transition
Scope: Story
Condition: Issue is in status Planning (the status the transition starts from)
Action: Limit Fix Versions to 3.1 (the next release)
Pattern 6: Dependent Dropdowns
One rule per value of the parent field. See Dependent Dropdowns.
Target: Subcategory (select list)
Condition: Category (select list) = Hardware
Action: Limit Subcategory to Laptop, Monitor, Peripherals
Troubleshooting
"Option disappeared but I need to select it"
Check:
- Does current context match limiting rule's conditions?
- Is there an active rule constraining the field?
- What's the current issue type, status, priority?
Solution: Either change context to make option available (e.g., change status), or update rule to include the needed option.
"Dropdown is empty / no options shown"
Check:
- Did the rule configuration specify which options to show?
- Do the selected options still exist in Jira, and are they enabled in the field's context for this project and work type?
Solution: Open the rule and review the options to show. Options are picked from the field's list and stored by id, so renaming an option in Jira doesn't break the rule; an option deleted in Jira can't be shown.
"User says they can't set the field value they need"
Check:
- Is there a limiting rule active?
- Does the user's role/context make them subject to restrictions?
Solution: Either expand rule to show needed option, or adjust conditions so rule doesn't apply in this context.
"Options aren't limited when I expect them to be"
Check:
- Are conditions met?
- Is rule enabled?
- Is rule on correct screen?
- Does scope match issue type?
Solution: Verify rule configuration. Test by checking if conditions evaluate to true.
Supported Fields Reference
| Field | Can Limit Options? |
|---|---|
| Priority | Yes (also on Issue View) |
| Issue Type | Yes (Create and Transition) |
| Fix Versions | Yes (Issue Transition only) |
| Single Select, Radio Buttons | Yes (also on Issue View) |
| Multi-Select, Checkboxes | Yes (also on Issue View) |
| Resolution, Components, Affects Versions | No: use a custom select list instead |
| Parent, Request Type, Cascading Select | No |
| Text, date, number and user picker fields | No (no options to limit) |
Limiting Options vs Other Actions
Understanding differences helps choose the right approach.
| Goal | Action | Use Case |
|---|---|---|
| Reduce dropdown choices | Limit Field Options | Show only P1/P2 for critical bugs |
| Hide entire field | Show/Hide Field | Don't show field at all in certain contexts |
| Set a default value | Set Field Value | Pre-fill dropdown with common choice |
| Prevent editing | Lock Field | Show dropdown but make it read-only |
| Require selection | Make Field Required | User must choose from dropdown |
Combined example:
- Hide Priority field when Issue Type not equals Bug (Show/Hide)
- Limit Priority to High, Critical for the Critical Infrastructure area (Limit Options)
- Pre-fill Priority = High by default (Set Field Value)
- Require Priority before submission (Make Field Required)
Related Patterns
Progressive Disclosure: Show fields conditionally; limit options shows field but filters choices
Pre-filling Values: Combine limiting with pre-fill for guided user experience
Dynamic Required Fields: Limit options + require field ensures valid, complete data
Next Steps
- Creating Your First Rule - Step-by-step guide to creating your first rule
- Defining Actions - Limit Field Options action details
- Progressive Disclosure - Show field, then limit options
- Pre-filling Values - Limit options and set default
- Dynamic Required Fields - Ensure valid selections
Ready to implement option limiting? Start with a simple priority or select list filtering rule and expand from there.