Guide · Jira

Jira approval workflow example: a purchase approval with three spend tiers

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.

Abstract advice does not build a Jira approval workflow, so this guide builds one: a purchase approval process in a company-managed Jira project, with three spend tiers, the right approvers in the right order, separation of duties and an audit trail. The same skeleton works for access requests, marketing spend or change approval.

The process

Tier 1, up to 5,000: the budget holder approves.
Tier 2, 5,000 to 50,000: the budget holder first; then finance checks the budget line and payment terms, and procurement confirms that quotes were compared.
Tier 3, above 50,000: the budget holder first; then finance, procurement and legal; finally the CFO.

Why tiers: a single process for a small software subscription and a large hardware order either slows down the small purchases or rushes the big ones. Tiered approval authority is common procurement practice and maps well onto Jira.

Step 1: work type and fields

Create a company-managed project, for example "PROC".
Add a work type (issue type) "Purchase request" with these fields: Amount (a Number field), Currency (a single-choice select list), Vendor (short text), Business justification (Paragraph) and Cost centre (a select list or short text).
Give the work type a workflow with the statuses Open, Awaiting approval, Approved, Rejected and Done.

Keep the fields minimal. Amount drives everything that follows, so it must be a Number field, not text.

Step 2: decide who approves

This is where the real risk is. Requirements to enforce:

The requester must not approve their own request (separation of duties).
In tiers 2 and 3, approvals happen in order: the budget holder before finance, finance before the CFO.
An approval should be a named, timestamped act, not someone editing a field.

In plain Jira you approximate this with a multi-user User Picker field "Approvers", a second field "Approved by", and restrictions on who may edit them. That works until someone with edit rights changes "Approved by"; the field history will show the edit, but there is no approval record as such. This gap is why dedicated approval apps exist; our guide Multiple approvers in Jira without Jira Service Management compares the routes.

Step 3: the workflow and the gate

Open the project's workflow in the workflow editor.
Transition "Open" to "Awaiting approval": unrestricted.
Transition "Awaiting approval" to "Approved": this is the gate. Something must check that the right people signed off for the tier.
Transition "Awaiting approval" to "Rejected": always available, with a transition screen that requires a "Rejection reason" field.

The built-in toolkit gives you conditions (for example Permission Condition, User Is In Space Role or Separation of Duties) and validators (for example Field Required). None of them can count "two of three named people approved" or check an order. Two realistic options:

Do it yourself: require "Approved by" to be filled (Field Required validator), and add a condition so only people in an approver project role can perform the transition. The counting and the ordering stay procedural: the approvers must keep to the order themselves.
An approval app with a workflow validator: you list the required sign-offs on the work item, and the validator blocks the transition to Approved until every required one exists. In Approval Flow, our app, each requirement can name up to 20 approvers and need 1 to 10 distinct sign-offs, stages 1 to 9 open in order, the person who added a requirement can be barred from approving it, and a rejection needs a reason.

Step 4: route by amount

How does a 6,000 request know it needs tier 2? Three ways:

Jira Automation: a rule triggered when a work item is created or when Amount changes can compare the amount and add a label or comment saying which tier applies. With an approval app that adds Automation actions, the rule can also request the right approvals: Approval Flow adds eight actions (paid), among them Request approval, Get approval status, Reset approval and Apply approval policy.
Manually: the requester or a project administrator applies the right tier. Honest, and fine at low volume.
App rules: Approval Flow's Approval rules (paid) add a requirement when a work item's fields match conditions. Conditions use the field ID, so for a custom Amount field the condition looks like customfield_10050 > 50000 (your ID will differ). Rules are evaluated when a work item is created, or when someone clicks Apply approval rules in the panel.

Approval Flow's template library has the three tiers above as ready-made templates: up to 5,000, 5,000 to 50,000 and above 50,000, with the stages already set. You add the named approvers.

Step 5: the audit trail

Later you need to reconstruct what happened: who approved what, when, in which order, and whether the amount changed after approval. Two protections are worth building in:

Re-approval on change. If the requester edits the amount after sign-off, the approval should reset. Plain Jira does nothing here. In Approval Flow, editing a requirement's text always clears its sign-offs, and with a paid licence a requirement can watch fields (given by field ID, such as the Amount field) and clear its sign-offs when one of them changes.
Export. For procurement, a record of decisions per quarter is not optional. Approval Flow exports each work item's audit trail as CSV or JSON from the panel, in every edition; with a paid licence, the Approval health project page shows what is waiting and for how long, and offers a CSV export for the project and an evidence export for any JQL search.

Step 6: test it before you trust it

Run three tests: (1) the requester tries to approve their own request; (2) someone moves a half-approved tier 2 request to Approved; (3) someone edits the amount after approval. Whatever you built, if any of the three succeeds silently, the control is cosmetic.

Jira approval workflow apps: what to look for

If you are choosing an app for a Jira approval workflow like this one, check these points before you install:

Your Jira plan. Jira's own native approvals need Premium or Enterprise (What are approvals?); ask whether the app depends on the plan.
A transition gate. A workflow validator that blocks the move until the sign-offs exist, and what it does when its own check cannot complete.
Quorum and order. Whether "two of these five" and "finance before legal" can be set, not just agreed.
Separation of duties. Whether the requester can approve their own request.
Re-approval on change. Whether editing the amount after sign-off clears the approval.
Export. Whether the decision trail leaves Jira as a file for procurement or an auditor.
The price at your size. The table shows the annual list price at 10, 50 and 100 users.

Our tracked list holds dedicated approval apps as well as sign-off and e-signature apps, so the rows below mix the two kinds. Earlier install counts for the approval apps, read on 12 October 2026, are in Multiple approvers in Jira without Jira Service Management.

App	Installs	Reviews	10 users	50 users	100 users
eSign Signatures for Jira	686	10	$0	$650	$1,300
Herzum Approval	302	17	$100	$500	$1,000
Electronic Signatures (Appfire)	296	23	$0	$545	$1,090
Approval Path for Jira	250	29	$100	$625	$1,250
Group Sign-Off	204	41	$55	$470	$940
Approval Flow (ours)	1	none yet	$0	$450	$900

Read from the Atlassian Marketplace data on 31 October 2026. Prices are the annual list price in USD for the first year at 10, 50 and 100 users. The rows are the 5 most-installed of the 9 approval, sign-off and e-signature apps for Jira in our tracked list, ordered by installs; this is not the order of the Marketplace search results, and apps outside our list are not shown. A blank install figure means the data held none. Star ratings are left out on purpose: the star field in the Marketplace data does not always match the rating shown on the listing, so open the listing for the current rating.

How our app helps

Approval Flow is our app. 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 one is granted, and fails closed if the check cannot be completed. It offers quorum, named approvers, sequential stages, separation of duties, out-of-office substitutes whose receipts record both people, rejections with a mandatory reason, and a hash-chained audit trail, all in every edition. Groups and project roles as approvers, policies, auto-apply by issue type, approval rules, watched fields, reminders and Automation actions need a paid licence.

Approval Flow is built for Jira Software and business projects and does not need Jira Premium. 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; without an active paid licence, a work item can still carry up to 500 requirements, the same as with one. See the documentation, the approval templates and the comparison with other approval apps.

Common questions

Can Jira do this without any app?

Partly. Fields, conditions and validators give you a manual process in which counting and ordering are procedural. That is workable at low volume and low risk, and stops being credible the first time someone edits an approval field.

Does this work on Jira Standard?

The do-it-yourself version works on any plan. Jira's own native approvals need Premium or Enterprise (What are approvals?). Approval Flow does not depend on the Jira plan.

How do I handle an approver being on holiday?

Look for delegation. In Approval Flow, an approver names an out-of-office substitute and a date range; the substitute's sign-off is recorded as "X on behalf of Y" and counts as the approver's.

Which apps can add an approval workflow to Jira?

Apps for approvals in Jira Software and business projects are a small category; the dated install counts are in the guide on multiple approvers. The table above holds the approval, sign-off and e-signature apps in our tracked list, with their annual list prices. Approval Flow is ours; the points above are the checks to run on any of them.

What about Jira Service Management?

Jira Service Management has native approvals and is a strong fit for request intake through a portal. Approval Flow is built for teams whose work lives in Jira Software or business projects; on JSM work items it can also show approval status on the customer portal and let a customer who is named as an approver approve or reject there, with a required reason for a rejection (paid; documented, not yet shown live with a portal-only customer).