How to Show or Hide Fields in Jira Based on Issue Type (Without Scripts)
If every Jira issue type uses the same long form, users either rush through it or skip important details. The fix is not a bigger checklist — it is conditional field visibility. By showing and hiding Jira fields dynamically based on issue type, you reduce form noise, improve data quality, and make every screen relevant to its context.
This no-code guide walks through how to show or hide fields in Jira based on issue type — with practical configuration blueprints, a 7-day rollout plan, and the most important traps to avoid.
What You Will Implement
By the end, you will have one clean pattern: relevant fields appear only when they matter, while irrelevant fields stay out of the way.
Why native Jira forms become noisy
Native Jira screens are static. That means if one field is needed for one issue type, teams often expose it for all issue types.
The result is predictable:
- bug-only fields on task forms,
- customer-facing fields on internal engineering work,
- lower completion quality because users cannot tell what actually matters.
Form fatigue
Users scan too many fields and miss the one field that is actually critical for this issue.
Inconsistent data
Teams submit minimal context because the form does not guide them to context-specific input.
Slow triage
Reviewers ask follow-up questions that should have been captured during issue creation.
The no-script approach
Instead of maintaining scripts, you can configure conditional visibility with Dynamic Screen Rules in your project settings. The approach is called progressive disclosure — showing fields only when context demands them.
The logic is simple:
- choose the right screen scope (Create, View, Transition),
- set a condition (for example,
Issue Type = Bug), - choose what should happen with the field (show, hide, require, lock, etc.),
- validate rule order and test with a real issue flow.
Configure in the app: show "Steps to Reproduce" only for Bug
Use this as your first baseline rule setup in Dynamic Screen Rules.
Recommended configuration:
- Rule name:
BUG - steps to reproduce visibility - Screen scope:
Global Issue Create - Condition type:
Context - Condition:
Issue Type = Bug - Action:
Show field -> Steps to Reproduce - Rule order: place above broad "hide for all" rules
- Test case:
- Create Bug -> field should be visible
- Create Task -> field should stay hidden
Why this works:
- Bugs get the extra context they need.
- Tasks and Stories stay cleaner.
- Users know what to fill based on current issue type, not generic instructions.
Configure in the app: show customer-impact fields only when external impact is true
This pattern helps support and incident teams.
Recommended configuration:
- Rule name:
INC - customer impact section visibility - Screen scope:
Global Issue Create - Condition type:
Field-based - Condition:
Impacted customers = Yes - Actions:
Show field -> Customer Impact SummaryShow field -> Escalation ContactShow field -> Public Status Link
- Rule order: keep this rule above generic "internal-only fields" rules
- Test case:
- Impacted customers = No -> all three fields hidden
- Impacted customers = Yes -> all three fields visible
This keeps high-friction fields hidden during routine internal issues, but visible the moment external impact is declared.
What users can configure in this app (beyond show/hide)
Scope by screen
Set rules for Global Issue Create, Issue View, or specific Transition dialogs.
Condition types
Use field-based, context-based (project/issue type/status), and user-based conditions.
Action types
Show/hide fields, make required, lock fields, set values, and limit options.
Rule governance
Control execution order, disable rules safely, and test changes before broader rollout.
7-day rollout plan for Jira admins
Day 1: pick one issue type pair
Start with a high-volume pair, for example Bug and Task, where form differences are obvious.
Day 2-3: implement 2-3 visibility rules
Add only rules that remove clearly irrelevant fields or reveal clearly required context.
Day 4-5: test with real creators
Ask team leads to create issues in both paths and report confusion, missing fields, or blockers.
Day 6-7: refine and expand
Adjust rule order, remove overlap, and extend the same pattern to next issue type group.
Common questions
Can I show or hide fields based on project instead of issue type?
Yes. Dynamic Screen Rules supports context-based conditions including project, issue type, status, and priority. You can combine multiple conditions — for example, show a field only in Project X when Issue Type = Bug.
Does hiding a field clear its value?
No. Hiding a field only removes it from the user interface. If the field already has a value saved on the issue, that value is preserved. This means you can safely hide fields on the edit screen without losing existing data.
Can I use this on Jira Service Management request forms?
Yes. Dynamic Screen Rules works on JSM request forms in the same way as standard Jira create screens. You can show or hide fields based on request type, priority, or any other supported condition.
What happens if I hide a required field?
If a field is both required (natively or by another rule) and hidden, users cannot submit the form. Always check that your hide rules do not target fields that are required on the same screen. See the conditional required fields guide for patterns that combine show/hide with make required safely.
Make Jira forms adaptive instead of overloaded
Start with one no-code rule set for issue types, then roll it out project by project.
Start trial on Marketplace