nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How many validators do you typically use on a transition? Curious minds want to know! 🤔

Thorsten Letschert _Decadis AG_

Hey, fellow workflow builders. 👋

I’ve got a quick question for the experienced Jira admins and workflow pros out there:

👉 How many validators do you usually add to a single transition?

And maybe even more interesting:

👉 What’s the maximum number you've ever used on one?

I’ve seen everything from clean and simple setups with just one validator to highly regulated processes with a dozen (yes, really). Sometimes it feels like we’re walking a fine line between good governance and overengineering 🙃

Now, the reason I’m asking:

With Forge rising, it looks like Forge-based (custom) validators might be limited to three per transition (at least for now). So I’m wondering if that's a dealbreaker for your use cases, or do most of your workflows fit comfortably within that limit?

I would love to hear your experience and examples, whether you’re keeping it minimal or going full control tower mode. ✈️

Let's compare notes!

P.S. If you’re more in the “automation-only” camp and don’t use workflows or validators much — I still want to hear from you! 💬

Let me know how you handle validation or control logic with automation rules instead. Always curious to see how others are solving the same problems from different angles. 🙌

Comments

Marcell Bendik

In our environment we handle some complex requests. Collecting all information is often not possible at once for the reporter.

So we have a initial status. The request stays there for multiple days, till the reporter has all information required.

Because of this:

- no mandatory fields at the time of creation

- multiple validation is required (up to dozen) when the reporter want to send the request

These use cases are valid, when the reporter also an agent (has license) and can edit the request, not just initially submit.

Sebastian Wigge

We mostly use validators for the following use cases:

1. On Creation transition to make sure data was provided in a specific manner

2. During the workflow, especially where transition screens are in place to have quality checks of user input or make sure data has changed

Usually we have between one and three validators in the affected transitions. Our current record is six validators in a create transition.

Tere Pile

We generally limit 2 per step in workflow, but I could see 3 being an option. We avoid automation because of limits w/standards.

John Elder

We often walk the fine line between automation and validators, choosing validators in specific places where it makes sense to a user actively in the tool, watching for the workflow to advance, etc... versus automation being used in places where the user likely makes a change and immediately moves on to other things. Usually our automations do not focus on workflow transitions as much which makes the differentiation easier, as well.

In terms of count, we currently only have a maximum of two validators on any step in the workflow, however I could also see adding a third in the future. We purposely avoid getting too complicated or "admin heavy" with the workflow and constraints, so I don't see the proposed limit as an issue for us.

Rune Rasmussen

We are mostly keeping it simply with no validators on most transitions.
There are a few with 5 or 6, but those are for quite niche situations.

One portion of control logic I've had to build, that I thought was quite challenging (at the time at least), was using status properties to simulate an approval step in a Jira Software project, where while in the "Validation" status the work item can only be edited by the person added to the "Validator" field, and automation enforces that when transitioning to the Validation status the Assignee and the Validator cannot be the same person, and a transition condition ensures that only the Assignee can transition to the Validation status.

In general we always try to consider the pros and cons of automation vs workflow configuration.
Often we can sort of achieve the same outcome with both, but one will usually be the best choice.

There is also the problem of visibility when it comes to workflow validators, in that there is no centralized overview of validators.
They are also hampered by the very early 2000's UI and options available when setting them up. The new workflow editor helps a bit but comes with a reduced number of available validators.
And if you're sharing workflows between multiple projects they can only be managed by product admins.

On the other hand, automations needs to be actively scoped to not just apply to any work item that can trigger the automation, unlike workflow validators that are inherently scoped to only the work items where the workflow is applied.
And they can be changed by project admins which may not always be desirable if a project is shared by multiple teams.

Anne Saunders

We have a Jira workflow-based 'Block' procedure that keeps the work item where it is in the flow (no need for a 'Blocked' column on the boards where work can go to moulder.

We use validation to ensure these issues can't transition until the 'Blocked' flag is released.

We also have a multi-step, multi-approver-per-step approval process in an internal project that ensures certain values are what they should be before allowing an item to progess via automation (or be progressed manually).

For literally all other control logic, we use automations.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-cloud

workflow