How to Require Fields on Jira Transitions (Without Workflow Validators)
Your issues move to Done without a Resolution. Bugs close without Root Cause. Releases ship without Release Notes. The data is missing because Jira workflow validators are hard to configure and offer no user guidance. The fix is transition-level field validation — quality gates that enforce data completeness at the exact moment it matters, with visible asterisks and inline error messages instead of generic rejection.
This guide shows how to require fields on Jira transitions — using screen-level quality gates instead of brittle workflow validators — without scripts or workflow admin privileges.
What You Will Implement
Three transition rules on different workflow steps: require Resolution before Done, require Release Notes before Ready for Release, and require Escalation Contact before Escalated. Each rule blocks the transition until the data is complete.
What workflow validators can and cannot do
Jira has built-in workflow validators, but they have hard limitations that make them impractical for most field enforcement.
Workflow Validators
Block transitions if conditions fail. But: no custom error messages, limited to simple checks, require workflow admin access to edit, and changes affect all projects using that workflow.
Dynamic Screen Rules
Show, require, or lock fields on the transition dialog itself. Custom validation messages explain what is missing. Rules are per-project and editable without touching the workflow.
The key difference: workflow validators reject the transition after the user clicks the button. Dynamic Screen Rules mark fields as required before the user submits — with visible asterisks and inline error messages. Users see what is needed upfront instead of getting a generic rejection. Learn more about how transition screens work in the documentation.
How transition screens work in Jira
Before creating rules, you need to understand one thing: rules can only affect fields that are already on the transition screen.
Check your transition screen
Go to Project Settings → Workflows → Edit workflow → Select transition → View screen. If the screen is empty or missing the field you want to require, add it first.
Rules evaluate against the target status
A rule with condition "Status = Done" applies when the issue is transitioning TO Done — not when leaving Done. This is how Jira's UI Modifications API works.
Required fields must be visible
If another rule hides a field that this rule requires, users cannot submit. Always place Show rules above Make Required rules in execution order.
Scenario 1: require Resolution and Root Cause before Done
The most common transition gate. Every closed issue should have a resolution value and, for bugs, a root cause analysis.
Test cases
Complete closure data
Every Done issue has a resolution. Bugs also have root cause. Dashboards and post-mortems get reliable, complete data.
No burden at creation
Users do not see Resolution or Root Cause when creating the issue. These fields appear only at the closure checkpoint.
Scenario 2: require Release Notes before Ready for Release
Release managers need release notes before a feature enters the release pipeline. This rule catches missing notes before they become a bottleneck.
Test cases
Combine with Set Value for smart defaults
Pair this rule with a Set Value action: auto-fill Fix Version with the current release version when transitioning to Ready for Release. Users still need to provide Release Notes manually, but Fix Version is pre-populated.
Scenario 3: require Escalation Contact on escalation
When an issue is escalated, someone needs to own the escalation. This rule ensures the contact is captured at the moment of escalation, not after.
Test cases
Notice the second action: Show field is paired with Make Required. The Escalation Contact field is hidden on all other transitions and only appears on the Escalated transition — where it is immediately required. For more patterns on combining actions, see the defining actions guide.
Field not showing on transition? Check this
If your rule is not working, walk through this checklist:
Is the field on the transition screen?
Project Settings → Workflows → Edit → Select transition → View screen. If the field is not listed, add it. Rules cannot affect fields that are not on the screen.
Is the rule scoped to the right transition?
Make sure the rule targets "Issue Transition" screen, not "Global Issue Create". Check that the status condition matches the target status (where the issue is going), not the source.
Is another rule hiding the field?
If a Show/Hide rule hides the field before the Make Required rule runs, users cannot fill it. Check rule execution order — Show rules must run before Make Required.
Does the workflow use the correct transition screen?
Some transitions have no screen configured (direct transitions). If there is no screen, there is no dialog, and no rules can apply. Add a transition screen in workflow settings.
Common trap: transition without a screen
If a workflow transition has no screen assigned, the status changes instantly with no dialog. Dynamic Screen Rules — and any field enforcement — cannot work without a transition screen. Always verify the transition has a screen in your workflow editor before creating rules.
3-day quick start
Day 1: pick one transition and one field
Start with the Done transition and the Resolution field. Verify the field is on the transition screen, then create one Make Required rule.
Day 2: test both paths and add a second rule
Test: move an issue to Done without Resolution (should block), then with Resolution (should pass). Add a second rule for Root Cause or Release Notes.
Day 3: expand to other transitions
Apply the same pattern to Ready for Release, Escalated, or any custom transition. Check for required + hidden conflicts and adjust rule order.
Common questions
Can I require fields on transition without workflow validators?
Yes. Dynamic Screen Rules lets you mark fields as required on the transition dialog itself — with visible asterisks and inline validation messages. This is more user-friendly than workflow validators, which reject the transition after the user clicks the button with no upfront guidance.
What happens if the transition has no screen?
If a workflow transition has no screen assigned, the status changes instantly with no dialog. Dynamic Screen Rules cannot work without a transition screen. Always verify the transition has a screen in your workflow editor before creating rules.
Can I require different fields for different issue types on the same transition?
Yes. Add a second condition to scope the rule by issue type. For example, require Root Cause on the Done transition only when Issue Type = Bug. Tasks moving to Done would not see or need Root Cause.
Do transition rules affect the issue create screen?
No. Transition rules target specific workflow transitions, not the Global Issue Create screen. If you want to require a field at creation time, use a separate rule scoped to Global Issue Create. See the conditional required fields guide for create-screen patterns.
Close the data gaps in your workflow
Add your first transition quality gate in under 10 minutes — no workflow validators, no scripts.
Start trial on Marketplace