6.2 Transition Rules: Conditions vs. Validators

6.2 Transition Rules: Conditions vs. Validators

Quick Summary: Workflow transition rules govern how and when issues progress through a lifecycle. In Jira Cloud, Conditions and Validators serve fundamentally different architectural and user experience purposes. Conditions act as pre-render gatekeepers: they evaluate server-side before the user interface renders, completely hiding the transition button if criteria are unmet. Validators act as post-submission inspectors: they execute after the user clicks the transition button and submits the transition screen, validating user inputs and aborting with helpful error messages if criteria fail. Understanding the operational distinction between "hiding for authority" versus "guiding for compliance" is vital for passing the ACP-120 exam.

---

Conditions: Pre-Render Gatekeepers

A Condition evaluates an environmental or issue-level prerequisite before Jira renders the issue view, mobile screen, or agile board transition menu. If any mandatory condition fails, Jira suppresses the transition button entirely. The user does not see the transition option, cannot click it, and receives no indication that the transition exists.

[User Views Issue]
        |
        v
[Evaluate Conditions Server-Side]
        |
   +----+----+
   |         |
[Met?]     [Unmet]
   |         |
   v         v
Render     HIDE Transition Button Completely
Button     (User has no visibility or access)

Where Rules Live in the Current Workflow Editor

The Jira Cloud workflow editor groups everything a transition can do under Rules. The blueprint and older documentation still use the classic names, so learn both:

Classic Conditions You Should Recognize

The classic conditions below map to the Restrict transition rules:

Grouping and Boolean Logic in Conditions

The legacy workflow editor lets you group conditions with boolean operators (the current editor combines multiple restrict rules on the transition):

• ALL of the following conditions must be met (AND): Every child condition in the group must evaluate to true.
• ANY of the following conditions must be met (OR): At least one child condition in the container must evaluate to true.

Administrators can nest condition groups inside other condition groups to create complex access rules:

ALL of the following conditions must be met (AND):
  ├── Sub-task Blocking Condition (All sub-tasks must be Done)
  └── ANY of the following conditions must be met (OR):
        ├── User In Project Role: Quality Assurance
        └── User In Group: site-administrators

---

Validators: Post-Submission Inspectors

A Validator evaluates criteria after the user clicks an active transition button and submits any associated Transition Screen. If the validation criteria evaluate to false, Jira aborts the transition, rolls back all pending changes, keeps the issue in its current status, and presents an informative error message directly to the user.

[User Clicks Transition Button]
        |
        v
[Display Transition Screen (User inputs data)]
        |
        v
[User Clicks 'Submit']
        |
        v
[Evaluate Validators Server-Side]
        |
   +----+----+
   |         |
[Valid]   [Invalid]
   |         |
   v         v
Commit    ABORT Transition & Rollback Changes
Changes   Display Actionable Error Message on Screen

Built-in Native Validators in Jira Cloud

Classic validators, now found in the Validate details rule group, include:

---

UX Architecture: When to Hide vs. When to Guide

A fundamental skill tested on the ACP-120 exam is determining whether a business requirement calls for a Condition or a Validator. The architectural rule of thumb is:

"Hide for Authority, Guide for Compliance."

+-------------------------------------------------------------------------+
|               DECISION MATRIX: CONDITION VS. VALIDATOR                  |
+-------------------------------------------------------------------------+
| Criterion                       | Use a CONDITION       | Use a VALIDATOR       |
+---------------------------------+-----------------------+-----------------------+
| Role / Authority Gating         | YES (Hide button)     | NO                    |
| Missing Data Collection         | NO (Causes deadlock!) | YES (Guide with error)|
| User Experience Feedback        | Silent suppression    | Explicit error message|
| Evaluation Point                | Pre-render            | Post-screen submit    |
| Prevents Screen Popups          | Yes (Button hidden)   | No (Screen opens)     |
+-------------------------------------------------------------------------+

Scenario 1: The Authority Gate (Use a Condition)

• Requirement: "Only designated QA team members should transition stories to 'Ready for Deployment'. Developers should not be allowed to perform this action."
• Solution: Apply a User In Project Role Condition (Role: QA).
• Rationale: Showing developers a button that immediately rejects their action with an error message generates UI clutter and frustration. Hiding the button keeps the interface clean and context-appropriate.

Scenario 2: The Compliance Gate (Use a Validator)

• Requirement: "When closing an issue, team members must select a 'Resolution' and input a 'Root Cause'. If omitted, the action must be rejected with instructions."
• Solution: Apply a Field Required Validator (Fields: Resolution, Root Cause) mapped to a Transition Screen.
• Rationale: If an administrator incorrectly configured a Condition checking that Root Cause is not empty, the user would see the transition button disappear entirely whenever Root Cause was empty! Because the field is empty prior to the transition, the user would never be able to make the button appear. A Validator keeps the button visible, opens the transition screen for input, and enforces data entry.

---

Critical Configuration Pitfalls & Deadlocks

Pitfall 1: The Missing Field Lockout (The Infinite Rejection Trap)

This is one of the most common and damaging mistakes in Jira administration:

1. An administrator adds a Field Required Validator to a transition (e.g., requiring the custom field Deployment Environment on the Deploy transition).
2. However, the administrator fails to add Deployment Environment to the Transition Screen associated with that transition, or fails to associate a transition screen altogether.
3. The User Experience: The developer clicks Deploy. The transition dialog appears (or attempts an immediate transition). The developer clicks Submit.
4. The Failure: Jira evaluates the validator and aborts with the error: "Field 'Deployment Environment' is required." However, because the field does not exist on the transition screen, the developer has no way to input the value!
5. The Trap: The issue is completely deadlocked. The developer cannot transition the issue forward, cannot satisfy the validator, and must contact the Jira administrator to fix the screen.

[Developer clicks 'Resolve'] 
       │
       ▼
[Transition Screen Opens] ───► Screen has: 'Comment', 'Assignee'
       │                       (MISSING: 'Root Cause' custom field!)
       ▼
[Developer clicks 'Submit']
       │
       ▼
[Validator Evaluates]: Is 'Root Cause' populated?
       │
       └──► [FAIL]: 'Root Cause is required!'
            Developer cannot satisfy validator! Issue is LOCKED!

[!CAUTION] Whenever you add a Field Required Validator to a workflow transition, you must verify that the required field is present on the Transition Screen mapped to that transition, AND that the field is not marked as "Hidden" in the project's Field Configuration.

Pitfall 2: Hidden Fields in Field Configurations

Even if a custom field is placed onto a Transition Screen, Jira will refuse to render it if that field is marked as Hidden in the active Field Configuration Scheme for that project and issue type. A Field Required Validator placed on that hidden field will continuously fail, producing an identical lockout to Pitfall 1.

Pitfall 3: Sub-task Blocking Circular Deadlocks

An administrator configures a Sub-task Blocking Condition on a parent issue requiring all sub-tasks to be in Closed before the parent can move to Closed. Concurrently, the administrator configures a condition or validator on the sub-task workflow requiring the parent issue to be Closed before any sub-task can close. Neither the parent nor the children can ever be completed.