JSM approval workflows: the complete guide (2026)

Affiliation note. This is written by Quietmill, an Atlassian Marketplace partner building in exactly this corner of JSM. Sources are linked throughout, and the section where our own app appears is clearly marked. Everything before it stands on its own.

It's written for the admin who has been handed a service desk and told "add an approval to this" — no prior approval configuration assumed. If you already run approvals at scale, skip to the failure catalogue, which is where the interesting problems live.

What an approval is in JSM (and what it isn't)

Some vocabulary first, because the rest of the guide leans on it.

Every Jira issue moves through a workflow: a set of statuses (the state the work is in — Open, In progress, Done) joined by transitions (the permitted moves between them). In JSM, a status can additionally carry an approval step.

That's the whole concept: an approval is a property of a workflow status, not a separate object you create somewhere. When a request enters a status that carries an approval step, JSM asks one or more designated people to approve or decline, and the request cannot leave that status through the approval transitions until the required decisions are in.

Three scope facts answer roughly half of all approval questions on the Atlassian community forums:

1. Approvals exist in JSM only. Jira Software and Jira Work Management have no native approval feature. A status named "Waiting for approval" in a software project is just a status with an aspirational name — nothing enforces anything. The open request to bring approvals to Jira Software is JRACLOUD-62053, with 580+ votes.
2. Approvals bind to statuses, not to request types. A request type is the portal-facing form a customer picks ("Request new software", "Order a laptop"); several request types normally share one workflow. Because the approval lives on the status, every request type using that workflow gets identical approval behaviour. If you need different approval rules for different request types, you need different workflows.
3. An approval decision is identity-locked. Only a listed approver can decide, the decision is recorded against the account that made it, and there is no approve-on-behalf-of — not in the UI, and not via the API. This is deliberate: an approval record is meant to be evidence. It also means "just approve it for me while I'm on holiday" has no supported answer, which is worth telling your approvers before they ask.

Setting up an approval step

You do this in the workflow editor, on the status itself: select the status, add the approval. Three configuration choices matter, and one of them quietly is your approval policy.

1. Where the approvers come from. Normally a user picker field — a field whose value is one or more Atlassian accounts — most often the built-in Approvers field. It is populated per request, by one of three routes: the requester chooses on the portal form, an agent sets it after triage, or an Automation rule fills it in. The third is the controllable option, and the next section is about why that matters.

2. How many must approve. One, all, or a specific number. "All" is the compliance-friendly default — nobody slips through. "One of N" is the availability-friendly one — the request keeps moving when somebody's away. Decide which risk you actually care about, because this single dropdown is most of your approval policy, and it's the setting people forget they chose two years later.

3. Where an approve and a decline each go. The outcome transitions. Both must already exist as transitions out of the approval status, or the step can't be saved. If the editor refuses to save your approval, this is almost always why.

Who can approve — the biggest cluster of questions

Controlling the approver list is the single most-asked approval topic of the last twelve months: how to restrict the field, how to map approvers by department or by request state, and — the one people ask about obliquely — how to stop requesters hand-picking the approver most likely to say yes.

The short version is that requesters should never populate the Approvers field directly. The working pattern:

1. Put a controlled choice on the portal form. A select list of departments, cost centres or request states beats an open user picker, because the requester is telling you what kind of thing this is rather than who they'd like to sign it off.
2. Hide the real Approvers field from the portal so it can't be set by the person making the request.
3. Map the selection to the authorised approver with an Automation rule on creation. "If department = Finance, set Approvers to …".

The mapping then lives in a rule that only admins can edit, which is the actual goal. Everything else — audit, consistency, not having awkward conversations about who approved what — follows from the requester not holding the pen.

A deeper piece on this is coming: team-managed and company-managed projects differ in where these controls live, and that difference deserves its own guide rather than a paragraph.

What approvers actually experience

This is the part most guides skip, and it's the part that explains the stalls.

When the request enters the approval status, each approver receives one email, carrying Approve and Decline buttons that work with a single click. That is the entire native notification plan. There is no follow-up, no daily digest, no "still waiting" surface anywhere in the approver's world. If that one email arrives during a holiday or gets swept into a mail rule, the request waits until a human happens to notice.

This single fact is behind most "our approvals sit for weeks" threads. The fix options differ enough from each other that we gave them their own post: Why Jira never reminds your approvers (and what actually works). The underlying request has been open on JSDCLOUD-8369 since 2018.

Two more things approvers can do, which are worth telling them about:

• Decide from the portal, under My approvals — useful for anyone who has already lost the email.
• Nothing else. Admins, separately, can see pending approvals per project.

And one fact that changes the economics: approvers who aren't agents don't need a licence. Approving is a customer-permission action. A finance director who signs off twelve requests a month costs you nothing, which is why approval workflows are one of JSM's genuinely cost-effective features and why it's worth building them properly rather than routing sign-off through email.

Group approvals

Instead of naming individuals, you can set a group as the source of approvers. Two behaviours reliably surprise admins:

• The notification goes to members individually. There is no group-inbox concept — every member gets their own copy of that one email.
• Visibility of who has already approved is limited. On a multi-approver request, the UI shows less than you'd expect about which group members have decided and which are still pending. JSDCLOUD-10260 tracks this, and Atlassian support has historically pointed people at the REST API for the pending list.

Tracking pending approvals

Four options, in ascending order of effort:

1. The project's approval views. Zero setup, limited reach — one project at a time.
2. JQL. Jira Query Language is the search syntax behind Jira filters. Approvals are queryable in limited ways — for example, finding requests waiting on a specific approver via the approver-based JQL functions.
3. Dashboards built on those filters. Same data, visible without anyone running a search.
4. The REST API. The service desk request-approval endpoints return per-approver pending and decided state. This is the source of truth whenever the UI shows less than you need — including the group case above.

Why approvals stall — the failure catalogue

Five failure modes account for nearly all of it. The first is famous; the rest are the ones that quietly cost you weeks.

1. The one email was missed. Covered above, and in more depth in the reminders post.
2. The approver left the company, or was deactivated. The approval can now never be answered, and nothing in the native UI flags it. The fix is manual: an admin edits the Approvers field — which resets the approval cycle for that step, so any decisions already made on that cycle stop counting.
3. The wrong approver was set in the first place. Same manual fix, same cycle reset.
4. Re-approval loops. When a request needs approval again — it was returned, or its scope changed — the step runs a fresh approval cycle. The UI shows the current cycle, so earlier decisions are easy to lose track of. The issue history tab retains them; getting them out in bulk needs the API.
5. Nobody escalates. JSM has no native "if this has been pending longer than N days, tell someone" behaviour. Teams build it in Automation or buy it.

Automation recipes that actually work

Jira Automation is the built-in rules engine — triggers, conditions, actions, configured per project. Three recipes cover most approval needs.

• Auto-set approvers on creation. Trigger on request created, then set the Approvers field from a mapped form field, using either smart values ({{issue.fields…}} — Automation's template syntax for pulling data off the issue) or a chain of If/Else branches per department. This is the foundation of every controlled approval flow, and the mechanical half of the "who can approve" section above.
• Scheduled reminder rule. A scheduled trigger plus a JQL query for requests sitting in the approval status, then a comment that @mentions the approvers.
• Escalation. The same scheduled shape with a longer threshold, but it comments to a named owner — your service desk lead — instead of the approvers.

Apps (disclosure: this section includes ours)

The recipes above have ceilings, and they're specific ones: pending-only targeting, buttons in the reminder, stop conditions, escalation state, deactivated-approver detection. When those ceilings are your actual daily pain, teams either build custom or buy.

We build Approval Nudge, a small Forge app covering exactly that list and nothing else. Other approval apps on the Marketplace cover adjacent ground — multi-step approval flows, approval paths spanning products — and if that's your gap, compare those first. Match the tool to the gap you actually have. For a lot of teams the scheduled Automation rule above is genuinely enough, and we'd rather you knew that.

This guide grows

Sections above will link out to deeper pieces as they publish — starting with the one on restricting and mapping approvers — and the guide gets refreshed when Atlassian ships approval changes. Several approval-adjacent tickets are In Progress on jira.atlassian.com as of writing.

Hit an approval situation this guide doesn't cover? Tell us about it — the gaps that keep coming up become the next sections.