Dynamic Required Fields
Dynamic required fields adapt validation to context. Instead of making fields always required or always optional, rules enforce validation only when relevant—based on priority, cost, status, or other criteria.
This keeps forms flexible while ensuring critical data is captured when it matters.
Why Dynamic Required Fields Matter
Problem: Static required fields create friction. Fields required for all issues become obstacles when they're only relevant to some scenarios.
Solution: Make fields required conditionally. Users encounter validation only when the field is actually needed for their specific case.
Benefits:
Faster issue creation - users aren't blocked by irrelevant required fields
Better data quality - validation appears when context makes the requirement clear
Flexible workflows - same form adapts to different scenarios
Reduced frustration - users understand why fields are required when they see them
Basic Pattern: Require Field When Condition Met
The simplest dynamic required rule enforces validation when a specific condition is true.
Example 1: Require Root Cause for Critical Bugs
Requirement: Root Cause must be filled for Critical priority bugs
Rule Configuration:
Screen: Global Issue Create
Target Field: Root Cause
Scope: Bug
Condition: Priority = Critical
Action: Make field required
User Experience:
User creates Bug with Priority = Low → Root Cause optional
User changes Priority to Critical → Root Cause becomes required (asterisk appears)
User cannot submit form without filling Root Cause
Validation appears exactly when it's needed
Threshold-Based Required Fields
Require fields when values exceed thresholds, ensuring oversight for high-impact items.
Example 2: Require Approval for High-Cost Features
Requirement: Features estimated over $10,000 must have Budget Code and Finance Approval
Rule 1: Show and Require Budget Code
Screen: Global Issue Create
Target Field: Budget Code
Scope: Feature
Condition: Estimated Cost > 10000
Action: Make field required
Rule 2: Show and Require Finance Approval
Screen: Global Issue Create
Target Field: Finance Approval
Scope: Feature
Condition: Estimated Cost > 10000
Action: Make field required
User Experience:
User creates Feature and enters Estimated Cost = $5,000 → No additional fields required
User enters Estimated Cost = $15,000 → Budget Code and Finance Approval appear and are required
Form cannot be submitted without these fields when cost exceeds threshold
Lightweight process for small features, proper governance for expensive ones
Status-Based Required Fields
Require fields at specific workflow stages, ensuring completeness before progression.
Example 3: Require Test Results Before Release
Requirement: Issues cannot transition to "Ready for Release" without Test Results
Rule Configuration:
Screen: Issue Transition
Target Field: Test Results
Scope: Bug, Story
Condition: Status = Ready for Release
Action: Make field required
User Experience:
User transitions Bug from "In Testing" to "Ready for Release"
Transition dialog shows Test Results as required field
Cannot complete transition without filling Test Results
Workflow gate ensures quality standards before release
Role-Based Required Fields
Require fields for specific user groups, applying different validation rules to different teams.
Example 4: Require Business Justification from Non-Managers
Requirement: Non-manager users must provide Business Justification when creating high-priority features
Rule Configuration:
Screen: Global Issue Create
Target Field: Business Justification
Scope: Feature
Conditions:
Priority = High OR Priority = Critical
User NOT in group "Managers"
Action: Make field required
User Experience:
Manager creates high-priority Feature → Business Justification optional (managers are trusted)
Team member creates high-priority Feature → Business Justification required
Different validation for different roles without separate forms
Multi-Condition Required Fields
Combine multiple conditions to enforce validation in very specific contexts.
Example 5: Require Release Notes for Production Fixes
Requirement: Bugs fixed in production releases must have Release Notes
Rule Configuration:
Screen: Global Issue Create
Target Field: Release Notes
Scope: Bug
Conditions:
Fix Versions is not empty
Component contains "Production"
Action: Make field required
User Experience:
User creates Bug without Fix Version → Release Notes optional
User sets Fix Version and Component = "Production" → Release Notes becomes required
Production releases are properly documented; non-production bugs aren't burdened with unnecessary fields
Practical Use Cases
Software Development Team
Require Acceptance Criteria for large Stories:
Scope: Story
Condition: Story Points > 5
Action: Require Acceptance Criteria field
Require Performance Impact for database changes:
Scope: Task
Condition: Component = Database
Action: Require Performance Impact field
Customer Support Team
Require SLA Deadline for Premium customers:
Scope: Customer Request
Condition: Customer Tier = Premium OR Customer Tier = Enterprise
Action: Require SLA Deadline field
Require Escalation Contact for high-severity tickets:
Scope: Support Ticket
Condition: Severity = Critical
Action: Require Escalation Contact field
Project Management
Require Risk Assessment for Epics:
Scope: Epic
Action: Require Risk Assessment field
Require Stakeholder Approval for scope changes:
Scope: Story, Task
Condition: Label contains "Scope Change"
Action: Require Stakeholder Approval field
Best Practices
Show Fields You Require
Always show a field before requiring it. Users can't fill required fields they can't see.
Good:
Rule 1: Show Budget Code when Cost > $10k
Rule 2: Require Budget Code when Cost > $10k
Bad:
Rule only requires field without showing it
Combine with Progressive Disclosure
Dynamic required works best alongside progressive disclosure.
Pattern:
Show field when relevant
Require field when critical
Example:
Show Root Cause when Priority = High (progressive disclosure)
Require Root Cause when Priority = Critical (dynamic required)
Use Clear Thresholds
Make conditions obvious so users understand why validation appears.
Good: Estimated Cost > 10000 (clear numeric threshold) Avoid: Complex multi-field calculations users can't predict
Screen Limitations
"Make Field Required" is not supported on Issue View due to API limitations. Use this action only on:
Global Issue Create ✅
Issue Transition ✅
Note: For Issue View field control, use Jira's native field permissions or workflow validators, as both "Make Field Required" and "Lock Field" are not supported on Issue View.
Common Patterns
Pattern 1: Priority-Based Required
Require additional fields for high-priority issues.
Pattern 2: Threshold-Based Required
Require fields when values exceed limits.
Pattern 3: Workflow Gate Required
Require fields before specific transitions.
Pattern 4: Role-Specific Required
Apply validation to specific user groups.
Troubleshooting
"User says field isn't required but should be"
Check:
Does the user's issue meet all conditions?
Is the rule enabled?
Is the screen correct (Create vs View vs Transition)?
Are you using "Issue View" screen? (Not supported)
Solution: Verify conditions match the user's context. Test with same selections.
"Field shows as required but user can submit without it"
Check:
Is there a conflicting rule removing the requirement?
Is the field hidden by another rule? (Hidden required fields can't be filled)
Solution: Review all rules affecting the target field. Ensure required fields are always visible.
"Required asterisk doesn't appear"
Check:
Is the action "Make Field Required" or something else?
Are conditions actually met?
Is the rule on the right screen?
Solution: Check rule configuration. Verify action type and condition evaluation.
Related Patterns
Progressive Disclosure: Show fields conditionally before requiring them - users see fields when relevant, required when critical
Field Locking on Transitions: Lock fields during status changes - different from required (supported on Create and Transition screens only)
Status-Based Validation: Combine with workflow to enforce completeness at transition points
Next Steps
Implement your first dynamic required rule:
Creating Your First Rule - Step-by-step guide
Combine with other patterns:
Progressive Disclosure - Show fields conditionally first
Field Locking on Transitions - Lock fields during status changes
Learn about conditions:
Defining Rule Conditions - Master condition types
Ready to implement dynamic required fields? Start with a simple priority-based rule and expand from there.
Last updated