Use cases

Field conditions

IDs used in following examples vary between Jira instances.

Is required

Issue must be assigned:

Jira expression

issue.assignee != null

Issue must have work logged:

Jira expression

issue.timeSpent != null

Comparing parent value in condition

Assuming that you have a separate workflow for sub-tasks and want to allow a transition in sub-tasks only when the field in its parent has the value "SAP":

Jira expression

issue.parent.customfield_xxxxx == "SAP"

It depends what kind of field you are referring. If it is of the Select type, then you need to use .value suffix:

Jira expression

issue.parent.customfield_xxxxx.value == "SAP"

It is up to you to find out the id and type of your custom field. In Jira expression field, after issue.parent. start typing the name of your field, you will get suggestion, which you can click and id of the field will be entered for you. You will also get a syntax error in case a type of the field is incorrect, which will help you make it right.

Finally, if you don't have a separate workflow, then you can make the condition to be checked only for subtasks, i.e. if parent != null. e.g.:

Jira expression

issue.parent != null 
    ? issue.parent.customfield_xxxxx?.value == "SAP"
    : true

Field mandatory depending on resolution

Make the "Root Cause" field required if the resolution is set to "Fixed":

Jira expression

issue.resolution != null && issue.resolution.name == 'Fixed' 
  ? issue. != null
  : true

Make the "Fix version" field mandatory only when the resolution is set to "Done":

Jira expression

issue.resolution != null && issue.resolution.name == 'Done' 
  ? issue.fixVersions.length > 0
  : true

Field value starts with

Summary starts with a string:

Jira expression

issue.summary.indexOf('Test Case') == 0

Summary starts with a string and is minimum 15 characters long:

Jira expression

issue.summary.indexOf('Test Case') == 0 && issue.summary.length >= 15

Compare different fields

The issue assignee must be different from the issue reporter:

Jira expression

issue.reporter != issue.assignee

Issue is in active sprint

Jira expression

issue.sprint?.state == 'active'

Original estimate field condition

The Original estimate field is stored as a number of seconds, e.g.: 4h = 4x60x60 = 14400.

Original estimate must be less than 4h:

Jira expression

issue.originalEstimate < 14400

Dates comparison

Due date is approaching in 2 days from now:

Jira expression

issue.dueDate != null 
	&& issue.dueDate < new Date().toCalendarDate().plusDays(2)

User conditions

Only the issue creator can close the issue.

In the Close transition add Jira Expression Condition or Validator (WBB):

Jira expression

user.accountId == issue.creator.accountId

Prevent the reporter from transitioning the issue (approval transition)

In the Approval transition add Jira Expression Condition or Validator (WBB):

Jira expression

user.accountId != issue.reporter.accountId

Linked issues

Prevent closing an issue if it has an “is blocked by“ issue linked

Jira expression

issue.links
  .filter(link => link.type.id ==  && link.direction == 'inward')
  .map(link => link.linkedIssue)
  .reduce(
      (pass, issue) => pass && ['done'].includes(issue.status.category.key),
      true
  )

Link type ID may vary between Jira instances. Use the Jira expression preview from the Linked Issues Condition to learn how to construct a similar expression.

Prevent closing an epic until all its issues are done

Jira expression

(issue.isEpic ? issue.stories : []).reduce(
  (pass, issue) => pass && ['done'].includes(issue.status.category.key),
  true
)

Restricting issue creation

1. Edit the workflow of issue type that you want to restrict

2. In diagram mode, select the Create transition arrow and click Validators in the properties panel.

3. Select the Validators tab and click on Add validator button

4. Add Jira Expression Validator (WBB)

Restricting the creation of certain issue types based on the user's project role

Requires a separate workflow for certain issue types

For example, if you want only users with the 'Developers' project role to be able to create Story issues, add Jira Expression Validator to the Create transition with following settings:

Jira expression

user.getProjectRoles(issue.project).reduce(
  (isAllowed, role) => isAllowed || ["Developers"].includes(role.name),
  false
)

Validation message

"You must have the Developer project role to create Story issues, but got: " 
  + user.getProjectRoles(issue.project).map(projectRole => projectRole.name)

Version without separate workflows

Jira expression

issue.issueType.name == "Story" 
  ? user.getProjectRoles(issue.project).reduce(
      (isAllowed, role) => isAllowed || ["Developers"].includes(role.name),
      false
    )
  : true

Field is required during a workflow transition for certain issue types

For example, to make the Story Points field required during creation only for the Story issue type, use the following expression. If you press Ctrl + Space after typing issue., start typing "story" to get suggestions about the Story Points field key.

Jira expression

["Story"].includes(issue.issueType.name) 
  ? issue.customfield_10036 != null
  : true

Note that thanks to our validator, there's no need to create separate workflows for each issue type.