Setting up workflows on JIRA is pretty much strait forward, but some times some of the very basic stuff seems lacking, or sometimes can only be achieved by using some extensions.
Today’s case would simply be possible had Atlassian developed the previous_state action. As usual in JIRA, adding new features demanded by users is not that common. However on this case, there’s a solution for this.
Problem statement
The scenario is around a state which has multiple entry points, and you wan’t the workflow to ensure that if a ticket can only go forward in the process, or backwards to the exact previous state, and not any of the others. The following diagram depicts one such case:
In the workflow above, the “MORE INFO NEEDED” state can be reached by a number of other states, namely “IN REVIEW”, “IN DEV” and “IN QA”, and can only move into one of those states. However, It wouldn’t make sense if you’d be able to have the following transitions “IN REVIEW” -> “MORE INFO NEEDED” -> “IN QA”. It would mean a ticket would have been solved without any development needed, but would still need to go through QA. Now, this is not a realistic case, and I won’t discuss how wrong this workflow is, but it the trick of demonstrating the use case.
So, the goal is to ensure that after a ticket has entered the “MORE INFO NEED” it can only move to the previous state.
How to do it
In this example I’ll use JIRA CLOUD, as available on the Atlassian free tier offering, and using a “Team-managed software” just to make it simpler to explain. Everything I’ll describe below is done almost exactly as on “Company-managed software”, except for the “hidden” parameter which is only supported on this mode.
First, this is the reality before the changes we’re about to perform.
Before, if the ticket would end up on “MORE INFO NEEDED” it would be possible to move to any of the 3 possible destination statuses, regardless of the previous state, which is what we want to avoid.
So, how do we do it?
First create a new parameter which will store the “previous state”. Let’s call it “PreviousState”.
Then, let’s add a rule, for each of the 3 transitions targeting the “MORE INFO NEEDED”, where the “PreviousState” parameter is set to the previous state name.
Then, for each of the transitions from “MORE INFO NEEDED” add a rule “Restrict to when a field is a specific value”
And then, select the “PreviousState” parameter, and set value to the previous state. This way, this transition will only become available if the “PreviousState” parameter matches the “PreviousState” the transition expects.
The outcome is well depicted by the following screenshots, of before and after.
That’s it folks!!
Maybe on the next opportunity we can dwelve on there JIRA workflow aspect.