Building Workflows Without Code

The ultimate collection of conditions, validators, and post-functions

See the workflow cheat sheet here [PDF]

Overview

Point-and-click Tools

40+ CONDITIONS, VALIDATORS & POST FUNCTIONS

SUPPORT ANY NUMBER OF USE CASES

Workflows are essential for the success of the business. They automate business rules to auto-assist users in deciding when one step has been completed successfully and the next step can begin. JMWE for Jira Server and Data Center provides a collection of workflow conditions, post-functions, and validators giving you all the building blocks you need to extend your workflows without code to support any number of business use cases.

See this Workflow Cheat Sheet [PDF] of all JMWE and Jira built-in conditions, validators, and post functions.

EASY POINT-AND-CLICK CONFIGURATION

Even if you are just starting out on workflow automation, it is easy to configure JMWE's conditions, validators and post-functions right inside the Jira workflow designer.

View Issue Transitions in the Activity Section [NEW!]

The transition history tab lets you easily see all issue transitions, when they took place, and who triggered them, all in one list. You can also see Time in status for each transition so that you can more easily evaluate the history of status changes of an issue.
See how it looks here.

Below is the list of JMWE conditions, validators and post-functions.

For the most up-to-date list, please refer to this documentation page. Also, take a look at this Jira Workflow Cheat Sheet - it lists all JMWE and Jira native conditions, validators, and post functions.

Quickly configure workflows using no-code tools to support any number of use cases

Workflows are essential for the success of the business. They automate business rules to auto-assist users in deciding when one step has been completed successfully and the next step can begin. JMWE for Jira Server provides a collection of workflow conditions, post-functions, and validators giving you all the building blocks you need to extend your workflows without code to support any number of business use cases.

Below you can view the list of JMWE post-functions (as well as Jira pre-installed optional post-functions), and the list of all conditions and validators available in JMWE for Jira Server.

For the most updated list and for more information, please refer to this page in the documentation.

Conditions

Previous Status Condition

Allows you to disable a particular transition (hiding it from the list of Available Workflow Actions) if the current Issue either:

has never been in the specified Status
or was not in the specified Status just before it entered the current Status (if "Most recent status only" is checked).

Use Case: A typical use for this workflow condition is when you can reach a certain Status from several other Statuses (through the same Transition) and want to be able to return to the originating Status. Consider the following partial workflow:

Jira will allow you to create a single Transition from both Open and In Progress statuses to the Waiting for clarification status. But how do you create the transition (Provide info) back to Open and In Progress? And, more importantly, how do you make sure the issue is transitioned back to the originating status? With “Previous status” condition.

Separation of duties condition

Enforces separation of duties (for SAS-70 compliance), i.e. that make sure the same user cannot trigger two incompatible transitions on the same issue. For example, you can prevent a user who has triggered the "Resolve Issue" transition on an issue to trigger the "Close" issue.

Hide transition

The purpose of the Hide Transition workflow condition is to hide a transition from the user, thus preventing the user from triggering it, while making it available to the Transition Parent Issue function or to scripts or remote API calls.

Scripted (Groovy) condition

Hides/shows a transition based on a Groovy expression.

Linked issues status condition

Allows you to hide/show a particular transition from the list of available transitions, based on the status of the issue's linked issues.

More information about JMWE Conditions can be found here.

Validators

Field has been modified validator

Forces users to modify a field during a transition.

Field required validator

Forces a field to have a value during a transition. You can optionally customize the error message displayed if the field has no value.

Comment required validator

Forces users to enter a comment during a transition. If they don't, a customized error message will be displayed.

Field has single value validator

Checks that a multi-valued field does not contain more than one value during a transition.

This can be useful, for example, to make sure users don't select more than one "Fix version" during the Resolve transition.

Previous status validator

Makes sure the issue has been in a specified Status before.

Parent status validator

Ensures that the current issue's parent issue is in one of the specified Statuses. This is useful only for sub-tasks.

Scripted (Groovy) validator

A workflow validator that is based on the result of a Groovy expression. If the Groovy expression returns false, a validation error message will be displayed.

Linked issues status validator

Ensures that the current issue's linked issues are in one of the selected statuses. For example, you can prevent an Epic to be closed until all of its Stories are closed.

Linked issue(s) validator

Enforces the creation of issue links during the transition, with certain characteristics, or to verify the existence of such links.

More information on validators can be found here.

POST-FUNCTIONS

Field Updating Post-Functions

Increase value of field

Increases the value of a numerical field by one

Set field value from user property value

Sets the value of a selected field of the current issue to the value of a User Property of the current user.

Set field value

Sets the value(s) of a selected field of the current issue. The value can be either a constant or the result of the evaluation of a Groovy expression or the result of a Groovy template.

Create/clone issue(s)

Creates a new issue. The specifications of the issue to be created can be customized using the options provided or by specifying a dynamic (calculated) issue type.

Copy field value to parent

Copies the value(s) of a field into the same field of the issue's parent issue.

Add field value to parent

Adds the value(s) of a multi-valued field (such as Fix version(s)) into the same field of the issue's parent issue or from an Epic to its Stories (or vice-versa).

Copy field value from parent

Sets a field value to the value(s) of the same field of the issue's parent issue.

Copy field value to linked issues

Copies the value(s) of a field into the same field of all issues linked to it through a specified link type. You can also use this function to copy a field from an issue to its sub-tasks, from an Epic to its Stories, etc.

Copy value from field to field

Copies the value(s) of a selected field to another field of the same issue.

Clear field value

Clears the value of one or more fields of the current issue.

Clear field value of linked issues

Clears the value of one or more fields on issues linked to the current issue.

Copy field value from linked issues

Sets a field value to the value(s) of the same field of an issue linked to it through a specified link type.

Set field value of linked issues

Sets the value(s) of a field on all issues linked to the current issue through a specified link type. The new value can be either a constant or the result of the evaluation of an arbitrary Groovy script. You can use this function to set the value of a field on the Epic of an issue, or on all issues of an Epic. You can also use this function to set a field of all sub-tasks.

Set issue security from user role

Sets the issue security level based on the Project Role to which the current user belongs.

This function can be used on the Create transition to set a different issue security level depending on whether the issue is being created by an internal user or by an external user (e.g. a customer)

Scripted (Groovy) operation on issue

Executes an arbitrary Groovy script against the current issue.

Link issues to the current issue

Links the current issue to all issues that satisfy a parameterized JQL query.

Unlink issues from the current issue

Unlinks issues from the current issue based on the result of a Groovy condition.

Set issue, user or project Entity Property value

Sets Jira "entity properties" on issues, projects, or users.

Communications Post-Functions

Email issue

Sends an email, including attachments, to certain recipients specified in the post-function configuration.

Comment issue

Creates a Comment on the current issue. The text of the comment can be either a fixed text, or the result of the evaluation of an arbitrary Groovy script.

Comment linked issues

Creates a Comment on linked issues. The text of the comment can be either a fixed text, or the result of the evaluation of an arbitrary Groovy script.

Display Message to User

Show a custom message on the issue view page to the user triggering the transition. For example, during a transition that creates a new issue, provide the user with a link to the newly created issue.

Assignment Post-Functions

Assign to role member

Assigns the current issue to the default member of the specified project role.

This can be used for scenarios like: "when a developer resolves the issue, assign the issue to the QA lead".

Assign to last role member

Assigns the current issue to the latest Assignee (excluding the current one) who is a member of the specified project role. If it finds a user that belongs to the specified role, it assigns the issue to that user. Optionally, it can consider the Reporter and/or the Current Assignee in addition to previous assignees.

This can be used for scenarios like: "when QA fails to assign the issue to the last developer who worked on it".

Transition Triggering Post-Functions

Transition Issue

Triggers a named transition on the current issue. This can be used to move the current issue one step further in the workflow, if a condition is fulfilled.

Transition parent issue

Triggers a named transition on the parent issue of the current sub-task.

Transition linked issues

Triggers a named transition on issues linked to the current issue through a specified link type. The Transition Linked Issues post-function can also be used to transition sub-tasks.

Return to Previous Status

Return the issue to the previous status, especially when multiple transitions lead to the same status, such as the “Escalated” status.

More information on post-functions can be found here.