A huge number of potential use cases can be addressed by using Jira expression mode which is currently a Cloud Only feature provided by Atlassian. Jira expressions can be a powerful tool but they come with limitations.
To master Jira expressions we strongly recommend reading the information we condensed on this single page. Especially when it comes to the difference between Jira expressions and the JWT expressions.
Use cases and examples
| Use case | JWT feature | Workflow function | Use case description | Complexity |
|---|---|---|---|---|
| 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. | ADVANCED | |
| 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. | BEGINNER | |
| 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. | BEGINNER | |
| Block a transition if a predefined field value has not been changed |
| Evaluate a Date Picker field and block the transition if it has not been updated. 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. | BEGINNER | |
| 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. | INTERMEDIATE | |
| Block a transition if the type of the attached files is incorrect |
| Evaluate the type of files in the Attachments field. 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. | INTERMEDIATE | |
| Check current issue status |
| Check whether the current issue is in a particular status. 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. | BEGINNER | |
| Check for at least one component |
| Require a at least one component. 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. | BEGINNER | |
| Check for unresolved sub-tasks |
| Check whether the current issue has any unresolved sub-tasks. This is particularly important if you want to block a parent issue 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. | INTERMEDIATE | |
| 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. | BEGINNER | |
| 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. | INTERMEDIATE | |
| Check the number of times that a field has changed |
| Check the number of times that a field has changed. 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. | INTERMEDIATE | |
| Current user must be reporter |
| Current user must be reporter. 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. | BEGINNER | |
| Due date must be in the future |
| The due date must be in the future. 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. | BEGINNER | |
| Evaluate custom fields |
| Evaluate custom fields of different types with Jira expressions. 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. | BEGINNER | |
| Evaluate the Parent Link 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. | INTERMEDIATE | |
| Evaluate the user |
| Evaluate users 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. | INTERMEDIATE | |
| Evaluate worklogs in sub-tasks |
| Evaluate if work has been logged in a sub-task to prevent transitioning the parent issue when no work has been logged. 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. | BEGINNER | |
| Issue must have at least two attachments |
| Require a at least two attachments. 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. | BEGINNER | |
| Make a field required only for stories |
| Make a field required to enable a transition only for issues with the story issue type. 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. | BEGINNER | |
| Make a fix version required and add a comment |
| Fields required or changed | Require a fix version and add a comment. This use case is valid for validators. | BEGINNER |
| Make the assignee required |
| Require a non empty assignee. 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. | BEGINNER | |
| Make values required in a Select List (cascading) field |
| Check whether a Select List (cascading) field has a value in 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. | BEGINNER | |
| Resolution must be empty |
| Not allow a resolution to be set. 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. | BEGINNER | |
| Validate an issue only if a comment is written during the transition |
| Evaluate the comments and hide 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. | BEGINNER | |
| Validate worklogs |
| Evaluate if a user has logged more than a certain amount of time in the latest worklog.
|
If you still have questions, feel free to refer to our support team.
