Ever wished a transition screen could just do what you need? Show a Rejection reason only on the Reject transition. Make an Impact assessment required only when Priority is Highest. Fill in Resolution the moment the Close screen opens. Native Jira can't do any of it, so you fall back on validators and cloned screens. Field Rules makes the transition screen react instead.
It runs live on the transition view in Jira, including Jira Service Management spaces, reacting to the values on the screen, who is running the transition, and now which transition it is. Here is what it can do.
Make the screen react
Show a field only when it's relevant. Reveal a "Rollback plan" field the moment "Change type" is set to "Emergency", and hide it again when it isn't. Native Jira has no conditional visibility on a transition: your only lever is a separate screen per transition, and even that can't branch on a field value or a user.
Require a field conditionally, and show it as required. Require an "Impact assessment" field only when Priority is "Highest". The field gets a real red asterisk and an inline error, and stands down if it isn't on the screen. The native workaround, a validator, shows no asterisk, fails only at submit, and blocks the transition even when the field is missing from the screen.
Filter a dropdown to what fits the moment. On a Release transition, show only the active Fix version, not the retired ones. On a bug's Resolve transition, trim a "Root cause" single-select to the causes that actually apply. Native field options are one static list, identical everywhere.
Pre-fill a value as the screen opens. When the Close screen loads, set Resolution to "Done" and drop a formatted "Closure summary" template into a rich text field, ready to finish. Native Jira can't: context defaults apply on Create only, and on a transition a field shows whatever the work item already had.
The rest of the toolbox
Every rule runs on the transition screen, not just those four:
- Lock a field read-only during the transition (Jira has no field-level read-only at all)
- Change a field's value reactively as another field changes on the screen
- Relabel a field just for this transition (a shared "Notes" field becomes "Reason for rejection" on Reject) without changing its global name
- Override a field's help text for this transition
- Restrict Assignee to self only during the transition
Target the exact transition
We just shipped transition conditions. A rule can now react to which transition is being run, not just that a transition screen is open:
- Transition name or Transition ID
- Destination status or destination status category (To Do, In Progress, Done)
That is the difference between "required on transition screens" and "required on this transition":
- Require the Rejection reason field only on the Reject transition
- Show deployment fields only when moving into a Done category status
- Lock a field once the work item leaves To Do
Less to maintain, not more
The native path is a screen per variation and a validator per transition, all static, none of it aware of a field value or a user. Field Rules replaces that with a handful of conditional rules that read like sentences and react live, on the screens you already have.
Try it free on the Atlassian Marketplace, or see what transition conditions can do.
Follow-up: Conditional fields in Jira - without scripting applies the same conditional behaviour across every Jira screen, with more real-world patterns to borrow.
