Conditional fields in Jira - without scripting

[#1]

If you manage Jira, you have probably hit this wall: a field that should only appear for bugs shows up on every work type. "Steps to reproduce" clutters a change request. "Rejection reason" is optional when it should be required. You know the screen is messy, but fixing it feels like opening a can of worms.

Screens and field configurations get you part of the way. But conditional behaviour - show this field only when that option is selected, require this field only for bugs - is not something they can do. That either means a scripting plugin and a developer to maintain it - or accepting the limitation.

Field Rules - UI Modifications for Jira is built for that gap. You configure conditional logic on Jira screens yourself, in the admin page - no scripting, no developer, no workflow changes. When requirements shift, you make the update yourself, the same day.

What a rule looks like

A rule has two parts: a condition and an action.

The condition describes when the rule applies - based on the value of another field, the work type, the space, or who is viewing it: their role, group, or identity. The action describes what happens - show a field, hide it, make it required, lock it, pre-fill it, or filter its options.

You configure rules in the Field Rules admin page. The same rule works on Jira work item screens and the JSM customer portal alike.

What you can do with it

Show and hide fields based on what's selected

A field on a Jira screen is either always visible or always hidden - there is no in-between. A "Vendor contact" field clutters every work item regardless of whether a vendor is involved. You can remove the field from the screen, but then it disappears for everyone - not just the cases where it is irrelevant.

With Field Rules, a field can be hidden by default and revealed only when a specific condition is met.

Example: a team tracks work items linked to external vendor tools. The "Vendor Tool Link" field should only appear when the account source is set to a specific vendor. One rule: show "Vendor Tool Link" when "Account Source" equals "Apex Cloud". For everything else, the field stays hidden. The field appears only where it's actually needed, instead of the all-or-nothing choice you'd otherwise be stuck with.

Branch into different field sets

When different request types need different fields, the usual workaround is separate work types - one per path, each with its own screen. Three paths means three work types, three screens, and three places to update when something changes.

With Field Rules, a single select field acts as a router instead. Different options reveal different sets of fields, each made required for that path.

Example: an operations team receives several types of internal requests. Choosing "System Configuration" reveals a "System Details" field and makes it required. Choosing "Performance Metrics" reveals a different field. Choosing "General Inquiry" reveals a notes field. One work type handles all paths cleanly.

Filter options based on another field

When two fields are related - component and sub-module, category and sub-category - nothing in standard Jira prevents users from selecting a combination that does not make sense. A reporter picks "Axiom CRM" as the component, then selects a sub-module that belongs to a different product entirely. The bad data goes through.

With cascading options, the child field filters automatically based on what the parent field contains.

Example: a platform team uses a "Component" field and a "Sub-module" field. Selecting "Axiom CRM" narrows Sub-module to three relevant options. Selecting a different component shows a completely different set. Invalid combinations are never selectable. That keeps the data clean at the source - no bad combinations to catch later in a report or clean up in bulk.

Restrict field access by role or group

Jira Cloud has no field-level permissions. A field is either on the screen for everyone or off it for everyone. If you want triage fields that only QA Leads should fill in, you have no native way to enforce that - you can hide the fields from everyone, or show them to everyone.

Field Rules lets you show, hide, or lock fields based on the current user's role or group.

Example: a QA team tracks defect reports. Root Cause and Impact Score are visible to everyone - but locked for everyone except QA Leads. Four additional triage fields are only visible to QA Leads at all. Everyone else sees fewer fields. Sensitive or specialist fields stay in the hands of the people who should be filling them in, and you are not relying on people to just know not to touch a field.

One place, not three

Behind every pain point above sits the same limitation: Jira cannot make a field behave conditionally on its own. Without a way to fix that directly, admins reach for whatever comes closest - a second work type, a duplicate screen, a separate field context per space. Each one gets close, but none of them actually branches on a condition, so admins end up maintaining near-identical copies side by side: screens that are almost the same field by field, field contexts holding almost the same option lists, work types someone has to remember to pick correctly when creating a work item. When one of them gets updated and the others do not, the setup quietly drifts out of sync.

With Field Rules, that duplication is not needed. One rule holds the condition and the action together, scoped to the spaces and work types it applies to. There is nothing to keep in sync, because there is only one place the logic lives.

---

The result: cleaner screens, fewer invalid entries, and fields restricted to the right people.

Field Rules is free for teams of 10 users or less, with a 30-day trial for larger teams: Field Rules - UI Modifications for Jira