List of Validators:

Required Fields Validator

This validator ensures that a field is required. It will mark such fields with a red asterisk (*) on the transition screen.

In Jira you can use field configurations to make fields mandatory. But this will make the field required on every screen it appears. In most cases users do not have all required information when creating issues, even if the information is required later in the workflow.

With this validator it is possible to make fields mandatory during any workflow transition to make the process more user friendly.

All custom fields and most system fields are supported. See here for details.

Example usage:

The custom field "Reason" must be filled before the transition is executed to "cancelled"
A comment must be added when closing an issue.
The single select field "Team" must have a value before proceeding to status "Ready for Development"

Execute validation on Condition NEW SINCE 11.4.0 & 9.15.0

Optionally you can define a Condition (choose from all available Conditions in system). The validation will only be validated if the Condition is met.

Example usage:

A comment must be added when closing an issue, but only if the Resolution is set to "Done"

Note:

The red asterisk will not appear on screens, if the validation is conditional.
After choosing a Condition, the page gets reloaded for initializing the corresponding JavaScript.

Please give us feedback for the conditional execution. We might add this feature to other Validators and Post Functions.

Regular Expression Validator

This validator can check if a certain field value matches a regular expression you define. It is quite powerful and its use cases range from a simple validation (where the user provided an exact value) to use cases where you check whether the user checked one or the other option in a cascading select list.

Parameters:

A Java regular expression the field value should match. Use this test page to check your expression.
(optional) A user-define error message if the validation fails

How are fields evaluated?

Date fields are in the format yyyy-MM-dd [HH:mm]
Multi values fields are separated by comma, like "OptionA, OptionB".

All custom fields and most system fields are supported. See here for details.

Examples:

To match "abc" use the expression abc.
To match a number between 0 and 5 use [0-5].
To match a String beginning with "TAN-" followed by any number (like "TAN-1234") use the expression ^TAN-[0-9]+
To check if OptionA has been selected in a multi value list use .*\b\s*OptionA\s*\b.*

Also available as Condition.

Validator to compare two Fields with each other

This validator enables you to compare two fields with each other.

Supported operators are:

Supported field types:

Date fields (both date and date with time)
Number fields
Assignee
All others fields only support '=', '!=' operator (comparison based on string implementation of the custom field type)

You can optionally compare with a value on the parent issue.

Both fields must be of the same type.

Note: For parent lookup, the validation will not fail if the issue has no parent (it is a subtask). This allows you to use the same workflow for parent and subtask issues.

Date Compare Validator

This validator compares a date field with a fixed date or a variable expression like +7d.

Supported field types:

Date fields (both date and date with time)

You can use a fixed date in format yyyy-mm-dd hh:mm or a pattern (days, weeks, months, years).

Examples:

2d = two days
-3w = three weeks ago
-10m = ten months ago
5y = five years from now

JQL Validator

This validator evaluates the current issue against a configured JQL expression.

Note: Data that has been currently changed during a transition can not be considered by a JQL expression, as these changes are not yet saved.

Additional configuration (optional):

Validator message
- Define a custom error message for the user if the validator fails. Leave empty for the default error message.
Run as user
- Define a technical user with which the JQL expression will be evaluated. If left empty, the current user during the transition will be used.

Examples:

"Start Progress" should not be possible if the status of the issue already was "Resolved"
- JQL query: status was not 'Resolved'

The possibilities with JQL are endless. We recommend reading the following article:
https://confluence.atlassian.com/jiracore/blog/2015/07/search-jira-like-a-boss-with-jql

Field Compare Validator

A validator that compares fields against a fixed value.

Supported operators:

=
!=
>
>=
<
<=
IN
NOT IN
CONTAINS

Supported comparison types:

String
Number
Option-ID

Examples:

The custom field 'total amount' must be <= 10.000
The label must be = 'Production'
The option-ID of custom field 'Department' must be != "100100" (we recommend comparing with option-ID's instead of values, because values might change over time)
The multi select custom field options must be contained IN "demo1, demo3"
The numeric custom field 'Odd Numbers' must be NOT IN "2, 4, 6, 8, 10"
The checkbox custom field 'Checklist' must CONTAIN "tested"

Supported Fields:

Number fields
Story points
Votes

Note: To compare against an empty field, just leave the comparison value blank.

Note: To split several values, just use a comma to separate, additional quotes are not necessary.
Valid examples: "first long string value, second long string value" or "14, 42, 13.37" (quotes in these examples are just used to highlight the configured values)

Note: fields that aren't present do NOT get evaluated. That means, for example, if you configure a custom field of type "single select" to be equal a fixed string value and that custom field is not set at all, the validation will result as invalid. To support the validation even if the field is not set, you have to configure an additional required fields validator for that field.

If you tick the checkbox it will validate the value from the child to the parent issue. The validator does not check whether there is a parent available.

Number Compare Validator DEPRECATED

deprecated

Number Compare Validator is deprecated and replaced by the Field Compare Validator. Please update your existing configurations.

Please note that the Validator is initially deactivated. You have to activate the module manually.

User In Project Role Validator

Validates that currently logged in user is in any or is not in any of the specified project roles.

Example: Only a user who is in the role "Developers" or "Users" can execute this workflow transition.

Also available as Condition.

User In Group Validator

Validates that the currently logged in user is in any or is not in any of the specified groups.

Example: Only a user who is in at least one of the following groups "My Group", "jira-administrators" or "project-admins" can execute this workflow transition.

Also available as Condition.

User in Field Validator

A validator to ensure that the currently logged in user is set on one (or many) custom field(s) (on the current or parent issue).

You have three options:

check that the current user is set in one/all field(s) or
or that she/he is not set in the (any of the) field(s)
or that she/he is set in at least one of the fields (option activates once more than one field is selected)

Supported custom field types

User picker (single user)
User picker (multiple users)
Group picker (single group)
Group picker (multiple groups)

You can also select group related custom fields. On validation the user will be checked, if she/he is member of the selected group (or at least one group, if multiple are selected). NEW SINCE 11.4.0 & 9.15.0

Parent Issue Type Validator

This validator prevents users from creating sub tasks for different parent issue types. You can add this validator to the "Create" transition from the sub task and validate if the parent is of the configured issue type.

You can configure a custom error message for this validator

Parent Issue Status Validator

Validates that the parent's current status is a specific status.

Linked Issues Status Validator

There are several use cases for this validator. Find some examples listed below:

Prevents users from closing an issue if there are any open blockers.
Prevents users from transitioning an issue if "Related" linked issues are not "approved" yet.
Prevents closing an epic if any related user story is not closed.

To configure the validator:

Select one or more issue link types.
Choose the direction of the link.
Select one or more allowed issue statuses of the linked issue.

This Validator supports a user defined error message.

Also available as Condition.

Field Values Changed (on Transition Screen) Validator

If you want a user to change a value on a transition screen, then this Validator will get the job done for you.

All custom fields and most system fields are supported. See here for details.

Browser not supported