Skip to main content

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.

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)
info

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

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: Status-Based Options​

Limit options based on workflow stage.

Condition: Status = Done
Action: Limit Fix Versions to released versions only

Pattern 3: Priority-Based Routing​

Show different components based on priority.

Condition: Priority = Critical
Action: Limit Component to specialized teams
Condition: Priority = Low
Action: Limit Component 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: Multi-Condition Filtering​

Combine context for precise control.

Conditions:
  - Issue Type = Story
  - Status = Planning
Action: Limit Fix Versions to next release only

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​

Field TypeExamplesCan Limit Options?
System Fields
PriorityIssue priority✅ Yes
ResolutionIssue resolution✅ Yes
Fix VersionsFix Versions field✅ Yes
Affects VersionsAffects Versions field✅ Yes
Issue TypeIssue type field✅ Yes
ParentParent issue field✅ Yes
Custom Fields
Single SelectCustom select fields✅ Yes
Radio ButtonsCustom radio button fields✅ Yes
Multi-SelectCustom multi-select fields✅ Yes
CheckboxesCustom checkbox fields✅ Yes
Service Management
Request TypeRequest Type field (JSM)✅ Yes
Not Supported
Text FieldsSummary, Description❌ No (no options to limit)
Date FieldsDue Date, Created❌ No (no options to limit)
Number FieldsStory Points❌ No (no options to limit)
User PickerAssignee, Reporter, Components❌ No (use Jira permissions)

Limiting Options vs Other Actions​

Understanding differences helps choose the right approach.

GoalActionUse Case
Reduce dropdown choicesLimit Field OptionsShow only P1/P2 for critical bugs
Hide entire fieldShow/Hide FieldDon't show field at all in certain contexts
Set a default valueSet Field ValuePre-fill dropdown with common choice
Prevent editingLock FieldShow dropdown but make it read-only
Require selectionMake Field RequiredUser 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)

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​

Ready to implement option limiting? Start with a simple priority or component filtering rule and expand from there.