Conditional validations in Workflows

[Asier Vadillo]

Hi everyone,

I’m trying to set up conditional validations for our Jira workflows. Due to budget constraints, we cannot use paid third-party plugins (like ScriptRunner or JMWE), so I'm trying to rely strictly on native features.

The workaround I've been using is based on this Atlassian article.

If I need a validation to trigger only when Field X is NOT Value Y, I create a duplicate transition and use condition rules to hide/show the appropriate path.

However, I am running into three major roadblocks with this approach:

• Limitation 1: Single-value restrictions. The native condition rule doesn't let you pick multiple values for a field. If my condition needs to be "Field X is NOT Value Y OR Z," I have to create multiple duplicate transitions. This gets messy quickly and leads directly to the next problem.

• Limitation 2: Hiding the original transition. To ensure users take the correct transition path, you must add an inverse condition to the original transition (e.g., "Field X IS Value Y" to hide it). But what if the rule is "Field X is NOT Value Y OR Z"? Because you can only pick one value in the restriction rule, you cannot hide the original transition for both cases (Value Y and Value Z). This leaves a loophole where users can use the wrong transition.

• Limitation 3: Global Transitions (Any to X). What do we do if the conditional validation needs to happen on a transition coming from Any status to Status X? Unlike standard transitions, Jira does not allow you to create two different Global Transitions pointing to the same destination status. Therefore, the duplicate transition workaround is impossible here.

Has anyone else fought against these specific native restrictions? Or does anyone have a different creative approach to achieve conditional validations without relying on paid apps?

Thanks in advance for any ideas!

Regards

[Trudy Claspill · Accepted solution]

Hello @Asier Vadillo 

The limitation you listed can be addressed as follows:

Limitation 1:

If the desired condition is "Field X value is not Y or Z" you could achieve that by using the ALL option for conditions.

Let us say you want to apply a validator only when the Priority field is neither "highest" or "high". You can do that thus"

Start by adding the Condition that Priority does not equal "highest".

Notice the MUST BE ALL in the above screen image. 

Now we add a second condition for Priority does not equal "high".

For this transition to be available the Priority field must not equal "Highest" and it must also not equal "High". That is the same logic as "Field X value is not Y or Z"

Limitation 2:

To hide the original transition in the above case again you would add two Conditions to it, and combine them with the CAN BE ANY option.

And change the "check if it" option to "equals" from "does not equal"

The transition with the above condition will display if Priority equals "Highest" or if Priority equals "High".

Limitation 3:

In this case you have one "global" transition and one bespoke transition that you reuse from all other statuses to the destination status.

Here is the Global transition where "Field X value is not Y or Z".

And here is the bespoke transition for the opposite, where "Field X value is Y or Z".

[Asier Vadillo]

Hi @Trudy Claspill ,

Thanks a lot for you reply.

The first limitation is solved thanks to you. The second limitation, about the global transitions I think will make the workflow unreadable so we are not going to implemented but it is also nice to have in case is needed.

Regards

[Arkadiusz Wroblewski]

Hi @Asier Vadillo 

You've done a thorough analysis and unfortunately I have to confirm that all three limitations you've hit are genuine native gaps in Jira Cloud. There's no clever trick that solves them all without a paid app.

The one native option worth considering as a partial workaround is Jira Automation. While it can't block a transition before it happens, you can set up a rule triggered by a status change that immediately reverts the work item back to its previous status and posts a comment explaining why the transition wasn't allowed. It's not great UX, but it's free, it covers the global transition limitation (since automation isn't bound by the same restrictions), and it can handle multiple field values in a single condition.

It's a post-validation rather than a pre-validation, which is the main downside. But for teams on a budget it's often the most practical native option available.

Beyond that, the honest answer is that what you're describing really does require something like ScriptRunner or JMWE. If budget is the blocker, it might be worth making the case internally with specific examples of the workflow complexity you're having to manage natively  sometimes that helps get approval.