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; } } }

Global context for workflow validator (ScriptRunner)

Ronny_matthies

Hi everyone,

I’m trying to enforce Kanban policies in a Jira Cloud company-managed project, for example:
- global WIP limits
- personal WIP limits
- entry rules for specific workflow states
- exception handling for certain service classes

The difficulty is that workflow validators seem to operate only within the context of the issue being transitioned. That works fine for issue-local checks, but it becomes problematic when the validation depends on global or cross-issue information, such as:
- how many issues are currently in active WIP statuses
- how many items are already assigned to a specific person
- whether exceptions should apply based on broader board state

A possible workaround would be to copy aggregated/global values into custom fields on each issue so validators can read them locally, but that feels awkward and hard to maintain.

Is there a cleaner or more standard way in Jira Cloud to implement this kind of policy enforcement, especially at transition time, without duplicating global state into every issue?

I’d be very interested in best practices or real-world approaches using native Jira Cloud, Automation, or ScriptRunner for Jira Cloud.

Thanks in advance.

Accepted answers

Arkadiusz Wroblewski

Hello @Ronny_matthies

I will explain you little Technical point.

That cross-issue logic is exactly where Jira Cloud hits a wall. Because workflow validators in Cloud rely on Jira Expressions instead of the full Groovy model from Data Center, they only evaluate the specific issue being transitioned.

They simply cannot run a live, global JQL check to count WIP limits or user workloads on the fly. Since Jira Expressions cannot query across the entire instance during a transition, a validator is unfortunately not the right place to enforce those kinds of global limits.

All comments

Marc -Devoteam-

HI @Ronny_matthies

I don't think this is possible,

WIP limits are board column bound and not on a user or project. So these need to be set on each board, you could do this by creating boards via API but then WIP limits are still per project and the Team working on it.

This is not a global setting to enforced.

The same applies to how may items are assigned, this is not a fixed number, as this can be based on the amount of work an item contains

What would be gained from this?

Arkadiusz Wroblewski

Hello @Ronny_matthies

I will explain you little Technical point.

Ronny_matthies

Hi,

thanks for your reply — I agree that Jira’s native WIP limits are board-specific and mainly visual.

What we want to achieve is actual process enforcement in the workflow: users should not be able to move issues onto the board if certain Kanban policies are violated, e.g.:
- a global WIP limit
- personal WIP limits
- defined exceptions such as Emergency items

So the benefit would be to enforce working agreements directly in Jira, independent of the board view, and prevent overload before it happens.

You are also right that item count is only a simplification. In our case, though, that is intentional — the policy is based on issue count, not effort.

Our real challenge is that workflow validators in Jira Cloud are very issue-local, while these policies depend on cross-issue information.

So the question is really whether there is a clean Jira Cloud pattern for enforcing such policies, other than copying global state into issue fields.

Marc -Devoteam-

Hi @Ronny_matthies

There are no condition or validation options for this within workflow, as they don't adhere to a board.

There are no global policies options to adhere to your need.

Also why, would you like to enforce this, no team is the same?

In my personal opinion, this would be very counter productive.
This would limit issue progress for user when they have a number of issues assigned and no more can be assigned, as some issues could be pending or planned to act by a user in the near future, etc.., etc..

But this is my personal and professional look on this.

Welcome!

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

Quick Links

Find more posts tagged with

scriptrunner

jira

cloud

jira-cloud

company-managed-projects