🚀 JWT 3.0 is out 🚀 

The app was completely overhauled, and so was the documentation: Jira Workflow Toolbox (Server/Data Center) Home

The page you are viewing is still valid for all app versions prior to 3.0.

On this page


Features used to implement the example

Jira Workflow Toolbox provides features for making issues automatically progress through the workflow. Issues that can be transitioned this way are:

  • Using post-function Update issue fields
    • Issues returned by a JQL query
    • Issues returned by a Issue List expression

Making issues progress through its workflow using a post-function

An issue can transition other issues progress through its workflow by executing a post-function for writing the name of target status (e.g., "Open", "In Progress", "Closed", ...) into virtual fields "Issue status" or "Issue status (delayed writing)", or the name of a transition into virtual fields "Execute transition" and "Execute transition (delayed execution)" on other issues.

Care must be taken to write the name of the status or transition exactly as it is. Since version 6.x, Jira shows almost always the status name in upper case. To check the real name of the status, try to edit it at Administration > Issues > Statuses > Edit. Since version 2.1.20, JIRA Workflow Toolbox is case insensitive for issue status, so you can write the name of the status as you see it in UI.


Writing into virtual field "Issue status"

When the name of a status (e.g., "Open", "In Progress", "Closed", ...) is written into virtual field "Issue status" on another issue, that issue will progress through its workflow to that status, whenever there is a transition from current status to the new one, and conditions and validators in that transition are currently satisfied. Post-functions in that transition will also be executed, the same way they are when transition is triggered manually.

Obviously, if there isn't a transition from current status to target status in the workflow of the issue we want to move, it will remain in its current status.


Why is needed another virtual field: "Issue status (delayed writing)"?

"Issue status (delayed writing)" works like virtual field "Issue status", with the only difference that effective status change is carried out after transition execution in current issue (i.e., the issue executing the post-function) has been completed. On the other hand, when writing into "Issue status", status change is done immediately (i.e. within transition). This delayed way of writing is very useful when the issue you want to make progress through its workflow (sub-tasks, linked issues or JQL selected issues) is blocked by the status of current issue. The cause for this blockage might be a condition or a validator that depends on current issue's status, like Block or hide a transition for an issue depending on its issue links, Condition and validation on sub-tasks, Condition and validation based on JQL query and Boolean condition and validator with math. date-time or text-string terms.


Virtual fields "Execute transition" and "Execute transition (delayed execution)"

Since version 2.1.20, there are two additional virtual fields for transitioning issues: "Execute transition" and "Execute transition (delayed execution)". These fields behave similarly to "Issue status" and "Issue status (delayed writing)" respectively, with the only difference that they expect the name of a transition, instead of the name of a status.

These new fields are particularly useful if you have global transitions in your workflow, or if you have more than one transition available for going to target status. With them you specify which transition you want to be executed.


Hiding a transition to interactive Jira users

Sometimes we add transitions to the workflow, intended to be triggered exclusively by post-functions. In these cases we hide the transition to interactive (human) Jira users using condition "Transition is triggered by Jira Workflow Toolbox post-function".


Features used for transitioning issues

  • Post-function Write field on linked issues or sub-tasks or Update issue fields, used to write into virtual fields "Issue status" or "Issue status (delayed writing)" the name of the target status we want to move issues to, or into virtual fields "Execute transition" or "Execute transition (delayed execution)" the name of the transition we want to execute.
  • Virtual fields "Issue status" or "Issue status (delayed writing)": when the name of a status is written into any of these fields, the plugin tries to executed any transition available from current issue status to the written status. Conditions and validations in the transition should be satisfied. These fields are selected in parameter Target field of post-function.
  • Virtual fields "Execute transition" or "Execute transition (delayed execution)": when the name of a transition is written into any of these fields, the plugin tries to executed a transition with the given name from current issue status. Conditions and validations in the transition should be satisfied. These fields are selected in parameter Target field of post-function.


Example: Automatically move issues to "In Progress" status once all its blocker issues are moved to "Closed", "Resolved" or "Done" statuses

In this example we edit 2 transitions in our workflows:

  1. Transition "Start Progress": we add a validation into transition "Start Progress" in order to prevent its execution whenever there are blocking issues in statuses different from "Done", "Resolved" and "Closed".
  2. Transitions "Done", "Resolve Issue" and "Close Issue": we add a post-function for to moving blocked issues to "In Progress" status. The validator added previously in "Start Progress" transition will prevent the execution of this transition while there still are blocking issues not yet closed or resolved.

These 2 transitions might be in the same workflow, or belong to different workflows.


Configuration of transition "Start Progress"

You can use any of these 2 validators in transition "Start progress" to block its execution until all blocking issues are in statuses "Resolved", "Closed" or "Done":
Validator Block or hide a transition for an issue depending on its issue links:





Once configured, transition "Start Progress" will look like this:



Validator Boolean Validator with math, date-time or text-string terms with the following configuration:



Boolean validation: count(linkedIssues("is blocked by")) = count(filterByStatus(linkedIssues("is blocked by"), "Resolved, Closed, Done")) 


Once configured, transition "Start Progress" will look like this:


Configuration of transitions "Done", "Resolve Issue" and "Close Issue"

Use post-function Write field on linked issues or sub-tasks to write the name of the transition we want to execute into field "Issue status (delayed writing)" of blocked issue. We use a boolean expresion in order to check whether the rest of blocking issues are already resolved or closed, and only when this boolean expression is satisfied the writing operation is actually done:





(info) If you are using Jira 7.0 or higher with versions of Jira Workflow Toolbox older than 2.2.8, you should input the following boolean expression in parameter Filtering by field values:

count(filterByStatus(linkedIssues("is blocked by"), "Closed, Resolved, Done")) = count(linkedIssues("is blocked by")) - 1

This way it prevents the transition execution whenever the validation is not satisfied.


Once configured, transition transitions "Resolve Issue", "Close Issue" and "Done" will look like this:


Other examples of that functions

Write field on linked issues or sub-tasks

Update issue fields

Block or hide a transition for an issue depending on its issue links

Boolean Validator with math, date-time or text-string terms

Related Usage Examples