Introduction
Sometimes one wishes an issue to pass through a set of transitions, but the order in which they are run does not matter. For example, if an issue must be approved by 3 different managers, the order usually doesn't matter.
JIRA uses the OSWorkflow library to manage transitions. OSWorkflow is technically capable of handling our situation, through its mechanism of splits and joins. Although JIRA's workflow editor is not capable of adding splits and joins, they can be added by hand to the workflow definition, in XML form, and this modified workflow loaded back into JIRA.
This page describes how to implement a simple split where 3 managers are required to approve an issue before it can be worked on:
/--> Manager1 Approves -\
/ \
(Create) -+---> Manager2 Approves ------> Open --> In Progress -> ...
\ /
\--> Manager3 Approves /

Try this at your own risk. JIRA does not 'know' about OSWorkflow splits and joins, and use of them will break parts of JIRA. Specifically:
Overall, you should only attempt to do this if you are happy to fix broken issues in the database if it all goes wrong. The relevant relations are described in the database schema documentation. |
Create an interim template workflow
First, create a workflow that is as close as possible to what we want. You probably already have a workflow, and want to add an approval step at some point. For this example, we take the default JIRA workflow.
Add new statuses
We wish 3 managers to approve our issue. We need a "Pending Approval" state for issues being approved. Create two other temporary statuses too:

Create new workflow
Copy the workflow you wish to add approvals to. Call it "Interim Approval Workflow" or somesuch, since we will not actually be using it in this form.

Now edit the interim workflow. Add new approval steps, each linked to one of the new statuses. Also add a transition to each to the step you wish the approval to end with. In our case, we want approved issues to be Open.
You probably want each approval step to be restricted to a certain group, so add a Condition to each step to meet your requirements.
The end result of all this editing will look like this:

Edit the workflow XML.
Return to the page listing the workflows, and click 'XML' to get a copy of the interim workflow's XML. Save this to disk.
We now need to edit the workflow XML by hand, to:
- Modify the transition that creates the issue, to split the issue into our 3 new steps.
- Modify our 3 steps so that their "ManagerX Approves" transition invoke a join (undoing the split).
- Modify our 3 steps to refer to the same status ("Pending Approval")
Adding a split
Open up the workflow XML in a text editor. At the end, before the closing </workflow> add the split definition:
Here we've defined a 'split' that results in 3 steps.
Now modify the transition where we want to invoke the split. In our case, we want to split immediately the issue is created, so we go to the 'initial' action, and change:
to:
ie. instead of resulting in step 1 ("Open") we result in split 1.
The step IDs in the join definition (7, 8, 9) should refer to the 3 steps we created:
The join is evaluated whenever an approval step is evaluated.
Adding a join
Similarly, add the join definition at the end of the file, before the </workflow>:
Again, make sure that the steps referenced (7, 8, 9) refer to the right steps.
We want this join to be invoked whenever a "ManagerX Approves" transition is run. So go to each approval step and modify the transition's unconditional result, eg. from:
to:
Note: we changed old-status to Finished, deleted the status attribute and replaced step="1" with join="1".
Do the same for Pending Manager2 Approval and Pending Manager3 Approval.
Make approval steps refer to same status.
We want all three approval steps (edited above) to refer to the Pending Approval state. Change:
to:
and:
to:
Import the edited XML
Now import the XML from the JIRA workflow editor. When importing, we've called it "Approval Workflow":

Clicking on it, it should look like this:

Apply new workflow
Now create a workflow scheme:

and associate it with a project.
Now try creating an issue. Immediately after creation, you should see 3 transitions available (depending on the conditions you placed on the steps):

Clicking on any 'Approve' transition will 'remove' it:


and after the last approval, the issue progresses to the 'Open' state:

Other Resources
- User discussion on Old Nabble
- JIRA Workflow Designer example of 3 People Approval Workflow

13 Comments
Hide/Show CommentsNov 28, 2007
Laurent BEDE
Hi,
how do I prevent a manager from approving more than once ?
thx,
Laurent
Feb 04, 2008
Yancy Way
This would be done in the groups that have permissions for each of these worflows. As long as you don't have someone in more than one of the approval groups, the manager should only be able to approve one time.
That said, I've already had to clean up a few issues in the DB after a few months of usage, so the warnings are apt!
Mar 04, 2008
Dean Vermeire
How do I prevent someone from going in and editing the other fields after the issue has been approved?
Aug 26, 2008
instrumentality
Can a workflow be selected through a combination of two or more field values? For instance, I would like to use this for change management. Suppose my "project" is a particular application--let's call it Easyapp. Also suppose I wanted to have a different workflow for standard changes (e.g. two people approve before the change goes to "Open" state) as opposed to emergency changes (e.g. one person approves before the change goes to "Resolved" state). Based on the fact that "Issue Type" is the only other field that pops up on the "Create New Issue" screen, I imagine I would need to set up new issue types "Change - Standard" and "Change - Emergency." How can I set this up such that the *workflow* is different for a standard Easyapp change vs. an emergency Easyapp change, and how do I set it such that the workflow structure is the same for changes to another app but different individuals/groups fill the approver slots?
Aug 05, 2009
Tyler Theobald
After being quite unhappy with previously posted solutions to handle multiple approvals, I've come up with a good solution using out-of-the-box functionality and the well supported JIRA Suite Utilities and Misc Workflow Extensions plugins. I hope this helps someone else...
2 parallel approvals (transitions) in a "Waiting for Approvals" step
"Bus Approves"
"Bus Rejects"
"IT Approves"
"IT Rejects"
Transition condition shows only for appropriate user/s
Transition goes right back to the same step "Waiting for Approvals", but sets a custom field (that doesn't show up on any screens) value
A scheduled service jelly script runs each minute and automatically transitions any issues (that result from a saved filter of requests that have been approved by both IT and Bus) to a new "Approved" step.
This method can be fully extended to handle all possible approval scenarios in my opinion. Works great.
Oct 21, 2009
Markus Khouri
Is it possible to create a workflow where 3 out of 5 managers need to approve the ticket, instead of having all the managers approved the ticket (in any order)? If so, I would appreciate any details into how this can be accomplished?
thanks.
Nov 23, 2009
Tyler Theobald
This can be accomplished through the general method of my previous post.
- Have transitions that go to the same step, but set custom field values (Manager approvals)
- Have a jelly script scheduled that automatically transitions any issues that match the criteria you want.
I know this is very general, but hopefully that gets you down the right path...
Jan 18, 2010
Matt Olson
Would it be possible post post a copy of your Jelly script to use an example?
Aug 17, 2010
Jason S. Wang
Any idea on how to solve the "Could not load condition" when using the following code in Jira 4.1.x?
I think the workflow library has failed to deal with beanshell.
I tried to replace the condition with some regular condition using class type like :
Split/Join works just fine.
Oct 09, 2010
Jason S. Wang
Oh well, it has been long since the comment and I had been busy.
After studying the workflow and plugin for a while, I fixed it myself by implementing the same logic as a custom workflow condition plugin.
It works just like using class type condition.
If anyone is interested, let me know.
Oct 12, 2010
Manny Lopez
I am having the exact same error "Could not load condition", after upgrading to Confluence 4.1.2. Can you post the steps you took to resolve the issue?
Oct 12, 2010
Jason S. Wang
Download
jar
source
Installation
copy the jar file into $JIRA_HOME/plugins/installed-plugins/ and restart Jira instance
Configuration
Modify the Workflow in xml format and replace the original beanshell condition with following code:
Then update the workflow using the modified XML
AND is the only logical operator implemented in this jar file.
For those issues that ran into "Could not load condition" error or has been created, you probably will have to delete them. The workflow migration will not be able to recover them for you.
Aug 25, 2011
gvsraju
Hi all,
Did any one tried this workflow transitions successfully with Jira 4.3.3#617-r149616?
I tried all of the above options and still getting "Could not load condition" error.
Any help will be highly appreciable.
Thanks,
Raju