Stanki Guild

Guide · Jira

Jira approval: 50% plus one when the approver group keeps changing

Approval Flow for Jira 3.0.0 is the production version (30 October 2026). Last updated 1 November 2026. On the Atlassian Marketplace.

By Bartosz Stankiewicz, founder, Stanki Guild.

A change board has eight members this month and twelve next month. You want "more than half of them must approve", not "exactly three". Atlassian's native settings are built around fixed numbers.

What the Community says about the native step

#

The question was asked in the Atlassian Community as Flexibility with amount of approvers (559 views and 12 comments when we read it on 30 October 2026). The asker needs 50% plus 1 of a group that changes often. Replies from other users say:

  • The approval settings offer a number, a number per group, or everyone: "None of those is a proportion."
  • One reply points to a workflow property: "That control writes a workflow property whose mode can be a percentage, so put it on 51 and the step works the number out from whoever is in the approver field." We have not tested this, and it is one user's description rather than Atlassian documentation.
  • Others advise a fixed, stable approver group and a change to the approval step instead.

Atlassian's tracker has an old related request, JSDCLOUD-4223, "Consider declined only when several approvers have declined": 30 votes, status "Under Consideration", open since 2016-08-30. It is about declining, not about proportions, but it shows the same gap: the rules for how many approvers decide are fixed.

Option: a percentage quorum in Approval Flow

#

Approval Flow (paid) lets a requirement count sign-offs as More than a percentage of them. You enter a whole number from 1 to 100. The people counted are the named approvers plus the members of any approver groups and project roles.

The rule is: more than the percentage of the people who may sign. With 50 percent, 9 people need 5 signatures and 10 people need 6. With 100 percent everyone must sign. The panel shows the result in words, for example "more than 50% of 9 people".

The detail that answers the "changing group" problem: the people are counted when you save the setting and again at every sign-off, and the count is stamped on the receipt. A requirement's result then follows from its stored receipts, so a group that grows or shrinks afterwards does not turn an approved requirement back into an open one. A group of more than 1,000 people is refused for this mode, with a message to use a smaller group or a fixed number.

Where this breaks: the count is taken when people sign, not continuously, so someone who leaves the group after the last sign-off does not change a requirement that is already approved. If you need the opposite, a requirement that re-opens when membership changes, this is not it.

What we have not shown live yet

#

The percentage quorum is in the production version 3.0.0, read from the released code (tag prod-3.0.0 of our Approval Flow repository), and it is covered by unit tests. We have not shown it on a live site, and it is not yet in the documentation page for the app. Quorums above one in general are in the same state: described, not shown live.

Common questions

#

Is percentage quorum free?

No. It needs a paid licence. Fixed quorums from 1 to 10 and "every named approver signs" are available in every edition.

Does it work with Jira's own approval step?

No. It applies to the sign-offs Approval Flow keeps on a work item, not to the native Approvers field.

#