JSM Approval Workflows: The Complete Guide (2026)

[#1]

Approvals are one of the most-asked-about features in Jira Service Management — and one of the least documented end to end. This guide covers the whole lifecycle: how approval steps actually work, who can approve, what approvers experience, how to track pending approvals, why approvals stall, and every real option for fixing the gaps — native, Automation, and apps. It gets updated as Atlassian ships changes.

Affiliation note: written by Quietmill, an Atlassian Marketplace partner building in exactly this corner. Sources are linked throughout; the app section at the end is clearly marked.

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

An approval in Jira Service Management is a property of a workflow status. 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 that answer half the approval questions on this forum:

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. The request for JSW approvals is JRACLOUD-62053, open with 580+ votes.
2. Approvals bind to statuses, not to request types directly. The same workflow gives every request type using it the same approval behaviour.
3. An approval decision is identity-locked. Only a listed approver can decide, decisions are recorded against the account that made them, and there is no approve-on-behalf — not in the UI, and not via the API.

Setting up an approval step

In the workflow editor, select the status and add the approval. The configuration choices that matter:

• Approvers source — a user picker field (usually the built-in Approvers field), populated per request: by the requester on the portal form, by an agent, or by an Automation rule (the most controllable option; more below).
• How many must approve — one, all, or a specific number. "All" is the compliance-friendly default; "one of N" is the availability-friendly one. Decide which risk you care about more, because this single dropdown is most of your approval policy.
• Outcome transitions — which status an approve goes to and which a decline goes to. Both must exist as transitions from the approval status or the step cannot be saved.

Who can approve — the biggest cluster of questions

Controlling the approver list is the single most-asked approval topic of the last twelve months: restricting the field, mapping approvers by department or request state, stopping requesters hand-picking a friendly approver. The short version: don't let requesters populate the Approvers field directly.

1. Put a controlled selection on the portal form — a select list of departments or request states beats an open user picker.
2. Hide the real Approvers field from the portal.
3. Map the selection to the authorised approver with an Automation rule on creation.

The mapping then lives where only admins can change it.

What approvers actually experience

When the request enters the approval status, each approver gets one email, with Approve and Decline buttons. That is the entire native notification plan. There is no follow-up, no digest, no "still waiting" — if that one email is missed, the request waits until a human notices. This single fact explains most "our approvals sit for weeks" threads, and the fix options are different enough that they get their own guide.

Approvers can also decide from the portal (My approvals), and admins can see pending approvals per project. Approvers who are not agents don't need a licence — approving is a customer-permission action, which is why approval workflows are one of JSM's genuinely cost-effective features.

Group approvals

You can set a group as the source of approvers. Two behaviours surprise admins:

• The notification goes to members individually — there is no group inbox concept.
• Visibility of who within the group has already approved — and who is still pending — is limited in the UI on multi-approver requests. JSDCLOUD-10260 tracks this; Atlassian support has historically pointed people at the REST API for the pending list.

Tracking pending approvals

In ascending order of effort:

1. The project's approval views — zero setup, one project at a time.
2. JQL — approvals are queryable in limited ways, e.g. requests waiting on a specific approver via the approver-based JQL functions.
3. Dashboards built on those filters.
4. The REST API — the servicedesk request approval endpoints return per-approver pending/decided state. The source of truth whenever the UI shows less than you need, including the group case above.

Why approvals stall — the failure catalogue

1. The one email was missed. Covered above.
2. The approver left the company or was deactivated. The approval waits forever; 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.
3. The wrong approver was set. Same manual fix, same cycle reset.
4. Re-approval loops. When a request needs approval again (returned status, changed scope), the step runs a fresh cycle — and the UI shows the current cycle, so earlier decisions are easy to lose track of. The issue history tab retains them; export needs the API.
5. Nobody escalates. JSM has no native "if pending longer than N days, tell someone" — teams build it in Automation or an app.

Automation recipes that actually work

• Auto-set approvers on creation. When request created → set Approvers from a mapped form field ({{issue.fields...}} smart values or If/Else per department). The foundation of every controlled approval flow.
• Scheduled reminder rule. Scheduled trigger + JQL for requests sitting in the approval status, then a comment that @mentions the approvers. Honest limitation: Automation cannot target only the approvers who haven't answered — pending-approver smart values don't exist (requested in JSDCLOUD-14352; Atlassian moved it to the Automation backlog in 2023, where it has sat since). Your rule reminds everyone or a hardcoded someone.
• Escalation. The same scheduled shape, but comment/notify a named owner (your service desk lead) instead of the approvers, after a longer threshold.

Apps (disclosure: this section includes ours)

When the automation recipes hit their ceilings — pending-only targeting, buttons in the reminder, stop conditions, escalation state, deactivated-approver detection — that's the point where 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 across products). Match the tool to the gap you actually have — for many teams the automation rule above is genuinely enough.

This guide grows: sections above link out to deeper pieces as they publish, and the guide is refreshed when Atlassian ships approval changes — several approval-adjacent tickets are In Progress on jira.atlassian.com right now.

[Dave LIAO]

I just voted up https://jira.atlassian.com/browse/JSDCLOUD-14352 - maybe one of these days it'll get done. 🙃