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.
Dynamic Screen Rules enables context-aware option filtering for cleaner, more intuitive forms.
Screen Limitation: The "Limit Field Options" action is only supported on Global Issue Create and Issue Transition screens. It is NOT supported on Issue View due to Atlassian's UI Modifications API constraints.
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, component, 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
Resolution - Issue resolution field
Fix Versions - Fix Versions field
Affects Versions - Affects Versions field
Issue Type - Issue type field
Parent - Parent issue field (for subtasks and child issues)
Custom fields:
Single Select - Custom select fields
Radio Buttons - Custom radio button fields
Multi-Select - Custom multi-select fields
Checkboxes - Custom checkbox fields
Service Management fields:
Request Type - Request Type field (Jira Service Management only)
Other field types: Text fields, date fields, number fields, and user picker fields don't have options to limit. Use this action only with fields that have predefined option lists.
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: Critical component bugs should only allow P1 and P2 priorities
Rule Configuration:
Screen: Global Issue Create
Target Field: Priority
Scope: Bug
Condition: Component = "Critical Infrastructure"
Action: Limit Field Options
Options to show: High, Critical (hide all others)
User Experience:
User creates Bug with Component = "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 Resolutions for Bugs vs Stories
Requirement: Bugs should have technical resolutions; Stories should have completion-focused resolutions
Rule 1: Bug Resolutions
Screen: Issue Transition
Target Field: Resolution
Scope: Bug
Condition: Status = Done
Action: Limit Field Options
Options to show: Fixed, Won't Fix, Duplicate, Cannot Reproduce
Rule 2: Story Resolutions
Screen: Issue Transition
Target Field: Resolution
Scope: Story
Condition: Status = Done
Action: Limit Field Options
Options to show: Completed, Declined
User Experience:
Closing Bug → Resolution dropdown shows technical options
Closing Story → Resolution dropdown shows completion options
Each issue type has appropriate resolution 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
Scope: Bug, Story
Condition: Status = Done (target status)
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
Priority-Based Option Filtering
Show different options based on issue priority.
Example 4: Limited Components 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: Component
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
Component dropdown shows only general options
High-priority tickets see all components (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: High-priority Stories should only target the current release; other priorities can target any version
Rule Configuration:
Screen: Global Issue Create
Target Field: Fix Versions
Scope: Story
Conditions:
Priority = High OR Priority = Critical
Action: Limit Field Options
Options to show: Version 3.0 (current release only)
User Experience:
User creates high-priority Story → Fix Versions shows only current release
User creates medium/low-priority Story → All versions available
High-priority work constrained to current release cycle
Practical Use Cases
Software Development Team
Limit priorities for different bug types:
Scope: Bug
Condition: Component = "Documentation"
Action: Show only Low, Medium priorities
Result: Documentation bugs can't be marked Critical
Restrict Fix Versions to current sprint:
Scope: Story, Task
Condition: Sprint = "Current Sprint"
Action: Show only versions in current release
Result: Sprint work targets appropriate releases
Customer Support Team
Show only customer-facing resolutions:
Scope: Customer Request
Condition: Status = Resolved
Action: Show Resolved, Won't Fix (hide internal options)
Result: Customer-facing issues get appropriate resolutions
Limit severity based on customer tier:
Scope: Support Ticket
Condition: Customer Tier = Free
Action: Show Low, Medium severity only
Result: Critical severity reserved for paying customers
Release Management
Show only unreleased versions for open issues:
Condition: Status != Done AND Status != Closed
Action: Show unreleased versions only
Result: Open work targets future releases
Limit Affects Versions to recent releases:
Scope: Bug
Action: Show last 3 versions only
Result: Prevents reporting bugs against ancient versions
Best Practices
Show Options, Don't Hide
Configure which options TO SHOW rather than thinking about which to hide.
Approach: List the valid options for the context; all others are hidden automatically.
Example: For critical bugs, show "High, Critical" (don't think "hide Medium, Low")
Combine with Pre-filling
Limit options AND set a smart default for best user experience.
Pattern:
Rule 1: Limit Priority to High, Critical for critical component
Rule 2: Pre-fill Priority = High by default
Result: Users see only valid options with reasonable default already selected
Don't Over-Constrain
Leave some flexibility unless business rules strictly require constraints.
Good: Limit to 3-4 most common options for specific context Avoid: Limiting to single option (just pre-fill instead)
Test with Real Users
Option limiting can feel restrictive if overdone.
Validation: Have users test forms to ensure they can complete common tasks without frustration.
Common Patterns
Pattern 1: Issue Type-Specific Options
Show different options for different issue types.
Pattern 2: Status-Based Options
Limit options based on workflow stage.
Pattern 3: Priority-Based Routing
Show different components based on priority.
Pattern 4: Role-Based Options
Show different choices to different user groups.
Pattern 5: Multi-Condition Filtering
Combine context for precise control.
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?
Are the specified options spelled correctly (case-sensitive)?
Do the specified options exist in Jira's field configuration?
Solution: Review rule configuration. Verify option names match exactly with Jira field options.
"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
System Fields
Priority
Issue priority
✅ Yes
Resolution
Issue resolution
✅ Yes
Fix Versions
Fix Versions field
✅ Yes
Affects Versions
Affects Versions field
✅ Yes
Issue Type
Issue type field
✅ Yes
Parent
Parent issue field
✅ Yes
Custom Fields
Single Select
Custom select fields
✅ Yes
Radio Buttons
Custom radio button fields
✅ Yes
Multi-Select
Custom multi-select fields
✅ Yes
Checkboxes
Custom checkbox fields
✅ Yes
Service Management
Request Type
Request Type field (JSM)
✅ Yes
Not Supported
Text Fields
Summary, Description
❌ No (no options to limit)
Date Fields
Due Date, Created
❌ No (no options to limit)
Number Fields
Story Points
❌ No (no options to limit)
User Picker
Assignee, Reporter, Components
❌ No (use Jira permissions)
Limiting Options vs Other Actions
Understanding differences helps choose the right approach.
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:
Show Priority field when Issue Type = Bug (Show/Hide)
Limit Priority to High, Critical for critical component (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
Implement your first option limiting rule:
Creating Your First Rule - Step-by-step guide
Learn about the action:
Defining Actions - Limit Field Options action details
Combine with other patterns:
Progressive Disclosure - Show field, then limit options
Pre-filling Values - Limit options and set default
See all use cases:
Dynamic Required Fields - Ensure valid selections
Field Locking on Transitions - Prevent changes during transitions
Ready to implement option limiting? Start with a simple priority or component filtering rule and expand from there.
Last updated