Guide · Jira

Multiple approvers in Jira without Jira Service Management: 3 ways compared

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.

Jira Service Management has had approvals for years. Jira Software and business projects did not, and people asked for them for a long time: the feature request JRACLOUD-62053 had 585 votes when we checked on 12 October 2026, and the 2018 Community question "How do I add an approval to a Jira software project workflow?" is still one of the most read threads on the subject.

That has partly changed. Atlassian announced native approvals for company-managed project types on Premium and Enterprise in October 2025 and approvals as a workflow step in February 2026. Atlassian's support page is explicit: "The approvals feature is only available on Premium editions in Jira" (What are approvals?).

The short answer: on Premium and Enterprise, native approvals cover multiple approvers. On Free and Standard, an enforced multi-approver sign-off needs fields and a validator you build yourself, an upgrade to Premium, or a Marketplace app. A required field cannot prove that two specific people approved.

So if you run Jira on the Free or Standard plan, or you need approval logic the native feature does not cover, you have three options. This guide compares them, including where each one breaks.

Option 1: build it yourself with fields and a validator

The classic do-it-yourself recipe, also described in an Atlassian Community article, Add an approval step using Jira Software and Work Management:

In Jira settings, create a custom field "Approvers" of type User Picker, set to allow multiple users.
Create a second field, "Approved by", of the same type.
Add both fields to the screens the project uses.
On the transition you want to gate (for example "In review" to "Done"), add the built-in Field Required validator for "Approved by".
Optionally, add a Jira Automation rule that notifies the people in "Approvers" when they are added.
Approvers add themselves to "Approved by" when they sign off.

What this costs: only setup time. Where it breaks:

Anyone who can edit the work item can edit "Approved by". The field says who is listed, not who approved; the work item history shows the field edit, but there is no approval record as such.
There is no quorum: "two of these five people must approve" cannot be expressed with a required field.
Nothing stops the requester from adding themselves, unless you also restrict who can edit the field, and maintain that.
The audit story is weak, as a Reddit thread titled "Apparently Jira doesn't track any info about release approvals?" describes.

Option 2: upgrade to Premium and use native approvals

Native approvals give you a real approval step on Premium and Enterprise: named approvers, approve and decline decisions on the work item, and, since February 2026, approvals as a workflow step.

Two caveats:

Cost. Atlassian's pricing page showed USD 8.48 per user per month for Standard and USD 15.56 for Premium on 20 October 2026 (the rates listed for 300 users, billed monthly), a difference of USD 7.08 per user per month. Rates depend on team size and billing period, so check the current pricing for yours. The upgrade buys much more than approvals.
Open items in Atlassian's own tracker. There is a long-standing report that approval steps can bypass workflow validators (JSDCLOUD-6988, 483 votes when we checked), and an open request for a screen that captures a comment when approving or declining (JRACLOUD-96793). If your control needs separation of duties (the requester must not approve their own request), test whether the native feature enforces it in your setup before you rely on it.

Premium is the right answer when you were going to upgrade anyway. It is an expensive answer when approvals are the only reason.

Option 3: an approval app from the Marketplace

Dedicated approval apps for Jira are a small category. Install counts read from the Atlassian Marketplace API on 12 October 2026:

App	Vendor	Installs
Herzum Approval	STAGIL by catworkx	298
Approval Path for Jira	Warsaw Dynamics	249
Group Sign-Off	Werkstack	208
Approval for Jira	Candylio	29
Business Sign-off	Cahaba Forge	5
Quorum Approvals for Jira	Smiling Monkey	1
Approval Flow for Jira	Stanki Guild (ours)	not yet listed on that date

Our comparison page lists their prices, ratings and features, with a source for each value.

A typical app in this category gives you named approvers, a quorum (N of M), a workflow validator that blocks the transition until the sign-offs exist, and a log of who approved or declined and when. Check each one for: support for your Jira plan, separation of duties, sequential stages, what happens when the validator cannot complete its check, and whether you can export the decision trail.

Which one to pick

One team, one gate, no budget, and you trust people not to edit the fields: build it yourself.
Already on Premium, or about to upgrade: try native approvals first.
You need a quorum, separation of duties or a real audit trail on Free or Standard: an app is usually the cheapest path that enforces the control.

How our app helps

Approval Flow is our app, and it appears in the table above. You list the sign-offs a work item needs and mark which are Required; the Approval sign-off required validator blocks the transition until every required sign-off is in, and if the check cannot be completed, the transition stays blocked. Each requirement can name up to 20 approvers and need from 1 to 10 distinct sign-offs. Requirements can be placed in sequential stages, and out-of-office substitutes sign on someone's behalf with both names on the receipt. With separation of duties switched on, the person who added a requirement cannot approve it, and the sole approver of a gating requirement cannot perform the transition. Rejections need a reason. Every sign-off, rejection and change goes into a SHA-256 hash-chained log, exportable as CSV or JSON, that nothing in the app can delete except the clean-up when the app is uninstalled. Jira groups and project roles as approvers are a paid feature.

Approval Flow is built for Jira Software and business projects and does not need Jira Premium. Without an active paid licence it still offers up to 500 requirements per work item, the same as with a licence, with named approvers, quorum, stages, separation of duties, the validator and the audit trail. It is free for up to 10 users with every feature, then from USD 0.90 per user per month for the first 100 users. See the documentation and the approval templates.

Common questions

Does Jira have approvals without Jira Service Management?

On the Premium and Enterprise plans, yes: Atlassian added native approvals to company-managed projects in October 2025, and in February 2026 announced approval steps in workflows for both team-managed and company-managed spaces. On Free and Standard, no; you need a workaround or an app.

Can I require two approvers on Jira Standard without an app?

Not in an enforced way. The do-it-yourself route can require that a field is filled, but not that two specific people filled it, or that the requester did not.

How do I keep an audit trail of who approved and when?

Editable fields give you little more than field history. Native approvals record decisions on the work item. Apps keep a decision log; Approval Flow writes every approval, rejection and change into a hash-chained log with CSV and JSON export.

Can an approval block a workflow transition?

Yes, through a workflow validator, which is the enforced path. Because of the open report about native approval steps and validators (JSDCLOUD-6988), test the exact workflow you plan to use.