Study guide
6.2 Transition Rules: Conditions vs. Validators
Atlassian Certified Professional - Jira Administration for Cloud ACP-120
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Overview, Blueprint & Jira Cloud Fundamentals
1.1 ACP-120 Exam Structure, Blueprint & Testing Strategy 1.2 Jira Cloud Architecture, Products & Admin Hierarchy
2 Chapter 2: Organizations, Managed Accounts & Global Access
2.1 Atlassian Organizations, Domain Verification & Managed Accounts 2.2 Atlassian Guard, SAML SSO, SCIM & Authentication Policies 2.3 Site Access, Product Access Tiers & Global Permissions 2.4 User Directory Architecture: Groups vs. Project Roles
3 Chapter 3: Project Permissions & Issue-Level Security Schemes
3.1 Permission Scheme Mechanics & Critical Project Permissions 3.2 Permission Troubleshooting, Additive Permissions & Permission Helper 3.3 Issue Security Schemes, Security Levels & Access Containment
4 Chapter 4: Project Configuration, Types, Versions & Boards
4.1 Company-Managed vs. Team-Managed Project Architecture 4.2 Project Templates, Project Keys & Project Categories 4.3 Project Components, Component Leads & Default Assignees 4.4 Versions, Fix Versions, Release Lifecycles & Project Archiving 4.5 Scrum and Kanban Board Configuration, Board Filters & Columns
5 Chapter 5: Issue Types, Custom Fields, Screens & Schemes
5.1 Standard vs. Sub-task Issue Types & Issue Type Schemes 5.2 Custom Field Types, Global vs. Project Contexts & Options 5.3 Field Configurations, Renderers, Hiding & Required Fields 5.4 Screens, Screen Schemes & Issue Type Screen Schemes
6 Chapter 6: Workflows — Company-Managed and Team-Managed
6.1 Statuses, Status Categories, Direct & All-to-One Global Transitions 6.2 Transition Rules: Conditions vs. Validators 6.3 Post Functions, Execution Order & Resolution Management 6.4 Workflow Schemes, Editing Active Workflows & Status Migration 6.5 Team-Managed Workflows, Statuses & Workflow Rules
7 Chapter 7: Jira Cloud Automation
7.1 Automation Engine, Rule Architecture & Event Triggers 7.2 Automation Conditions, Smart Values & String/Date Expressions 7.3 Branch Rules, Related Issues, Sub-tasks & Parent Epics 7.4 Rule Scopes, Automation Usage, Audit Logs & Error Handling
8 Chapter 8: Notifications, Events, Personal Settings & Mail Handlers
8.1 Jira Events, System Events & Notification Schemes 8.2 Notification Recipients, Custom User Fields & Deduplication 8.3 Team-Managed Notifications, Personal Settings & Troubleshooting Missing Email 8.4 Mail Handlers: Creating Issues and Comments from Email
9 Chapter 9: JQL, Filters, Dashboards & Bulk Operations
9.1 JQL Fundamentals, Clauses, Operators & History (WAS / CHANGED) 9.2 Advanced JQL Functions & Dynamic Date Searches 9.3 Filter Permissions, Shared Filters & Filter Subscriptions 9.4 Dashboard Layouts, the Default Dashboard, Sharing & Essential Gadgets 9.5 Bulk Operations: Edit, Move, Transition, Delete & Watch
10 Chapter 10: System Administration
10.1 Global UI Features: User Defaults, Look and Feel, Announcement Banner & Default Dashboard 10.2 Statuses, Resolutions, Priorities & Sub-tasks: Global Configuration 10.3 Global Settings: Time Tracking, Issue Linking, Attachments & Application Links 10.4 System Backup, Restore & Data Import
6.2 Transition Rules: Conditions vs. Validators
Key Takeaways Explain This Topic AI
Conditions are evaluated before a transition is rendered, completely hiding the transition button from users who do not meet the criteria.
Validators are evaluated after a user clicks the transition button and submits the transition screen, aborting the transition with an actionable error message if criteria fail.
The core UX design principle is 'Hide for Authority, Guide for Compliance'—use conditions for role and permission gating, and validators for data collection and validation.
A critical configuration pitfall is enforcing a Field Required Validator for a field that is absent from the transition screen, causing an inescapable transition lockout.
In the current workflow editor, conditions appear as Restrict transition rules, transition screens as Request input, validators as Validate details, and post functions as Perform actions.
Last updated: September 2026
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 Name (Blueprint) Rule Group in the Current Editor Example Rules
Conditions Restrict transition Restrict who can move a work item (role, group, assignee, reporter, permission, user field); restrict to when a field is a specific value; restrict to when the issue has been through a status; restrict based on the status of sub-tasks; restrict from all users
Transition screen Request input Show a screen
Validators Validate details Validate a field (required, changed, single value, dates, regular expression); validate that people have a specific permission; validate that the parent is in a specific status; validate that the issue has been through a status
Post functions Perform actions Update a work item's field (including clearing it); assign a work item; copy a field's value; set a security level; trigger a webhook
Classic Conditions You Should Recognize
The classic conditions below map to the Restrict transition rules:
Condition Type Operational Mechanism Common Practical Use Case
User In Project Role Checks if the current user is assigned to a specific Project Role (e.g., Quality Assurance , Release Managers ). Restricting approval transitions (such as Pass QA or Approve Deployment ) strictly to authorized personnel.
User In Group Checks if the current user is a member of a global Jira user group. Reserving emergency overrides (such as Force Close ) to jira-administrators .
Only Assignee Condition Checks if the user attempting the transition is the currently assigned user on the issue. Ensuring that only the developer currently working on an issue can move it to Ready for Review .
Sub-task Blocking Condition Prevents the parent issue from transitioning unless all child sub-tasks occupy specific statuses or categories. Blocking a parent User Story from transitioning to Done until 100% of its child sub-tasks are in Closed or the Done category.
Permission Condition Verifies that the user holds a specific project permission (e.g., Resolve Issues , Close Issues , Schedule Issues ). Aligning transition availability with standard project permission schemes.
Value Field / Compare Number Custom Field (now "Restrict to when a field is a specific value") Compares a field's value against a fixed value. Restricting Approve Budget transitions to issues where Estimated Cost <= 5000 .
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:
Validator Type Operational Mechanism Practical Administrative Scenario
Field Required Validator Checks that one or more specified fields contain a non-null value before the transition commits. Requiring Fix Version/s , Resolution , or a custom Root Cause field when closing a bug.
Permission Validator Verifies that the user possesses a designated project permission at the exact moment of execution. Enforcing Close Issues permission validation during transition execution.
Previous Status Validator Asserts that the issue occupied a specific previous status immediately prior to the current status. Preventing an issue from being moved to Resolved unless its preceding status was Under QA .
Regular Expression / Pattern Evaluates a text or custom field value against a regex pattern. Validating that a Change Request ID field matches the strict syntax CR-[0-9]{5} .
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:
An administrator adds a Field Required Validator to a transition (e.g., requiring the custom field Deployment Environment on the Deploy transition).
However, the administrator fails to add Deployment Environment to the Transition Screen associated with that transition, or fails to associate a transition screen altogether.
The User Experience: The developer clicks Deploy . The transition dialog appears (or attempts an immediate transition). The developer clicks Submit .
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!
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.