This validator allows you to address a huge number of potential use cases by writing custom Logical mode or Jira expression mode. Both are powerful tools with different strengths and limitations.
Logical expressions use JWT's built-in expression syntax and are optimized for field-based conditions directly within the workflow context. They are generally easy to read and write for common use cases such as comparing field values, checking issue properties, or combining multiple conditions with logical operators. On top of that, logical expressions support JQL natively - allowing you to query and validate against sets of issues using Jira's familiar query language directly within your expression.
Jira expressions are evaluated by Atlassian's Jira Expressions engine and give you access to the full Jira data model - including related issues, linked issues, project properties, and more. This makes them significantly more flexible for complex scenarios. The trade-off is that Jira expressions have stricter resource limits (e.g., execution time, data depth) enforced by Atlassian, and the syntax may be less familiar to non-developers.
As a rule of thumb: start with a logical expression for straightforward field validations or JQL-based issue checks, and reach for a Jira expression when you need deeper data access or more complex programmatic logic.
🛠️ Configuration
Notes
You can optionally enter a short Note (limited to 80 chars) and a longer Explanation (limited to 500 chars) to summarize what you are using the function for. This can help you differentiate multiple functions of the same kind in a single transition, as the Note will be shown in the workflow transition view.
Expression
In general, we recommend using logical expressions. They cover most use cases, are supported by our Expression Generator and the supported fields and functions continuously extended by us. If you intend to use Jira expressions instead, we strongly recommend reading the information we condensed on this single page. In this case also note the special case below.
Enter a Logical expression or a Jira expression depending on the chosen Parsing mode to define what about the issue should be validated.
The result of the expression must either be true if the validation passes or false if the validation fails.
Error message
Enter the message to show to the end-user when the validation fails. In case you don't enter a message, the default error Message for JWT for Jira Cloud "Validation failed for validator 'Logical validator (JWT)'" is displayed in case of a failing validation.
Test expression
We highly recommended to test your expression before publishing the workflow. Click on 
Learn more about how to test an expression!
📚 Use cases
| Use case | Workflow function | Use case description |
|---|---|---|
| Block a transition based on the day of the week |
Block transitions on weekends or any other day of the week. This use case is valid for both conditions and validators. The only difference is that you can specify an additional error message when using a validator. |
|
| Check whether an attachment was added during the transition. |
Make sure that the current user has uploaded a attachment during the transition. This use case is valid for both conditions and validators. The only difference is that you can specify an additional error message when using a validator. |
|
| Check if an attachment was added recently |
Make sure that the current user has uploaded a attachment during a definite period of time. This use case is valid for both conditions and validators. The only difference is that you can specify an additional error message when using a validator. |
|
| Block a transition if some issues under an epic are not in a certain status |
Check whether an epic has all issues under it in a certain status. This is particularly important if you want to block an epic as long as work is still being done on related sub-tasks. This use case is valid for both conditions and validators. The only difference is that you can specify an additional error message when using a validator. |
|
| Block a transition based on issue links |
Evaluate issue links and hide transitions based on the outcome. This use case is valid for both conditions and validators. The only difference is that you can specify an additional error message when using a validator. |
|
| Validate worklogs |
Evaluate if a user has logged more than a certain amount of time in the latest worklog.
|
|
| Evaluate the Parent field |
Evaluate different values of the issue in the Parent Link field of the transitioned issue. This use case is valid for both conditions and validators . The only difference is that you can specify an additional error message when using a validator. |
|
| Validate an issue only if a comment is written during the transition |
Evaluate the comments and block transitions based on the outcome. This use case is only valid for validators as it involves making changes during a transition. An additional error message can be added. |
|
| Ensure all work for a release is completed |
Make sure that a release can only proceed once all work items assigned to the same fix version have been completed. This can be useful for release approval or deployment transitions where you want to prevent a release from moving forward while unfinished work is still associated with it. |
|
| Block a transition based on sprint information |
Make sure that an issue is not in an active sprint. This use case is valid for both conditions and validators . The only difference is that you can specify an additional error message when using a validator. |
|
| Prevent users from starting too many work items |
Prevent users from starting too many work items at the same time. Before a work item can be moved to In Progress, the validator checks how many other work items are already assigned to the same user and currently in the In Progress status category. This can help teams keep work-in-progress under control and encourage users to finish existing work before starting additional items. |
|
| Check parent issue type |
Check whether the parent of the current issue is of a certain issue type. This is particularly important if you want to reuse a workflow for multiple sub-task issue types but only want a transition to be available if the sub-task belongs to a certain user story or a bug. This use case is valid for both conditions and validators. The only difference is that you can specify an additional error message when using a validator. |