Jira Conditional Required Fields: Require Data Only When It Matters
When a Jira field is always required, low-priority issues get cluttered with forced input nobody reads. When a field is always optional, critical issues ship without the data your team needs for triage. The fix is conditional validation — require data only when it actually matters, based on priority, issue type, or workflow status.
This guide walks through three real configuration patterns for conditional required fields in Jira Cloud — based on priority, based on another field's value, and on workflow transition — without scripts or workflow hacks.
What You Will Implement
Three conditional required rules: one triggered by priority, one by a field value, and one on a workflow transition. Each enforces data completeness only where it matters — and stays invisible everywhere else.
Why "always required" breaks your forms
Native Jira gives you a binary choice: a field is required for every issue, or it is never required. There is no middle ground.
Teams try to compensate, but every workaround creates a new problem:
Missed critical data
High-priority incidents close without the detail needed for post-mortem and prevention — because the field was optional.
Form fatigue
Users fill required fields with "N/A" or "TBD" to get past validation on routine issues — because the field was always required.
False completeness
Every field has a value, but half the values are placeholders. Reports look full but say nothing useful.
The root cause is the same in all three cases: Jira does not let you say "this field is required only when this condition is true."
The conditional approach
Instead of choosing between "always" and "never", you define a condition. The requirement activates only when the context demands it. This pattern is called dynamic required fields — enforcing validation only when it adds value.
Pick the screen scope
Decide where the rule applies: Global Issue Create, Issue View, or a specific Transition dialog.
Set a condition
Choose what triggers the requirement: priority level, another field's value, issue type, user role, or a combination.
Choose action: Make Required
The field gets a red asterisk and blocks submission only when the condition is true. When it is not — the field stays optional or hidden.
Scenario 1: require Root Cause only for Critical priority
The most common conditional required pattern. Root Cause is essential for post-mortems on Critical issues, but irrelevant for routine tasks.
Test cases
Critical gets root cause
Every high-priority incident captures the analysis needed for prevention — enforced, not requested.
Routine stays clean
Low-priority issues skip the field entirely. No placeholder entries polluting your data.
Triage trusts the data
When a field is always filled on Critical issues, reviewers stop asking follow-up questions.
Combine with Show/Hide for cleaner forms
Pair this rule with a Show/Hide rule: hide Root Cause by default and show + require it only when Priority = Critical. Users on routine issues never even see the field. See the show/hide fields guide for the setup pattern.
Scenario 2: require Escalation Contact when Customer Impact = Yes
This pattern uses a field-based condition — the requirement activates based on the value of another field, not issue metadata like priority.
Test cases
This keeps escalation fields invisible during routine internal issues, but the moment someone declares customer impact, the system enforces accountability — no training manual required.
Scenario 3: require Resolution on transition to Done
This pattern targets a workflow transition instead of the create screen. Issues cannot close without proper resolution data.
Test cases
Governance at the right moment
Data quality is enforced when the issue closes — not when users first create it and have no resolution yet.
Reliable reporting
Every closed issue has a resolution value. Dashboards and audits get consistent, complete data.
Watch out: required + hidden conflict
If a field is both required and hidden by different rules, users cannot submit the form — they cannot see the field they need to fill. Always check that your "Make Required" rules do not target fields hidden by another rule on the same screen. Rule order matters: place "Show" rules above "Make Required" rules.
Native required vs Dynamic required
Native Required
Always required for all issues on the screen. No conditions, no custom message. Best for universal fields: Summary, Priority, Issue Type.
Dynamic Required
Required only when a condition is true. Supports priority, field value, issue type, user role, and transition triggers. Custom validation messages guide users.
Use native required for fields that every single issue needs — these never change based on context.
Use dynamic required for fields that matter only in specific situations — Root Cause for Critical, Escalation Contact for customer-facing issues, Resolution on closure. For detailed examples and configuration patterns, see the field validation examples documentation.
5-day rollout plan
Day 1: audit your current required fields
List every field marked "always required" in your screen configuration. Flag fields where users frequently enter "N/A" or placeholders — those are your first candidates.
Day 2: implement first conditional required rule
Start with the highest-impact case: usually Root Cause for Critical priority. One rule, one screen, one condition.
Day 3: add a field-based conditional rule
Pick a field that depends on another field's value — like Escalation Contact when Customer Impact = Yes. This validates field-based conditions work in your setup.
Day 4: test both paths with real users
Ask two team members to create issues: one that triggers the condition, one that does not. Verify the required asterisk appears and disappears correctly.
Day 5: review and expand
Check for required + hidden conflicts, adjust rule order if needed, and plan conditional rules for transition screens or other projects.
Common questions
Can I make a field required only for specific issue types?
Yes. Use a context-based condition with "Issue Type = X" to trigger the Make Required action. For example, require Root Cause only for Bugs, or require Customer Impact only for Incidents. The field stays optional for all other issue types.
What happens if a user edits an old issue that does not meet the new required rule?
Dynamic required rules apply to the current form state. If the field is empty and the condition is true, the user must fill it before saving. If the field already has a value, the rule is satisfied. This means existing issues are not blocked unless users try to edit them without the required data.
Can I combine "Show Field" and "Make Required" in one rule?
Yes, and this is the recommended pattern for conditional required fields. First, show the field when the condition is true. Then, make it required. This keeps the field both hidden and optional when the condition is false — cleaner than making it required but invisible.
Does this work on Jira transition screens?
Yes. Conditional required fields work on Global Issue Create, Issue View, and all Transition screens. See the transition validation guide for specific transition patterns.
Stop forcing data where it does not belong
Set up your first conditional required rule in under 10 minutes — no scripts, no workflow hacks.
Start trial on Marketplace