Use case
Evaluate custom fields of different types with Jira expressions.
🛠️ Configuration
Add a Logical validator or a Jira expression condition to the transition of your choice
Fields
Follow the instructions to evaluate any type of custom field depending on your preference.
For every example, the expression editor must be set to Jira expression and the Field codes IDs must be replaced.
Date Time Picker
JWT expression*
{system.currentDateTime} < {issue.cfnnnnn}
The selected date and time is posterior to the current date and time.
Date Picker
JWT expression*
datePart({system.currentDateTime}, RUN_AS_LOCAL) < {issue.cfnnnnn}
The selected date must be posterior to the current date.
Select List (single choice)
JWT expression*
%{issue.cfnnnnn} != null
The field must not be empty.
JWT expression*
%{issue.cfnnnnn} = "Option 01"
The selected option must be a specific value.
JWT expression*
["Option 01", "Option 02"] ~ %{issue.cfnnnnn}
The field must contain one of two specific values.
Select List (multiple choices) and Checkbox
JWT expression*
toStringList(%{issue.cfnnnnn}) ~ "Option 01"
One of the options values must be a specific value.
JWT expression*
%{count(toStringList(%{issue.cfnnnnn}))} > 2
More than two values must be selected.
JWT expression*
toNumber(jiraExpression("issue?.customfield_nnnnn && issue?.customfield_nnnnn?.some(c => c?.value && c?.value?.match('Option 01'))")) = 1
Only a specific value must be selected.
JWT expression*
%{issue.cfnnnnn} != null
The field must not be empty.
Select List (cascading)
JWT expression*
%{issue.cfnnnnn} = "Option 01"
The parent value must be a specific value.
JWT expression*
toNumber(jiraExpression("issue?.customfield_nnnnn?.child?.value == 'One'")) = 1
The child value must be a specific value.
JWT expression*
toNumber(jiraExpression("issue?.customfield_nnnnn?.value == null && issue?.customfield_nnnnn?.child?.value != null")) = 1
The parent value must be empty and the child value must not be empty.
Short text and Paragraph
JWT expression*
%{issue.cfnnnnn} = "This is a text"
The field value must match exactly a text.
JWT expression*
%{issue.cfnnnnn} ~ "is a text"
The field value must contain a text.
📚 Related 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. |