JSM approvals: setup, approvers and troubleshooting

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 distinctions help explain how approvals work:

1. This guide covers JSM request approvals. Jira also offers approval features in some business spaces; their setup and availability differ. Atlassian's business-space approvals documentation explains the distinction.
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. Requiring everyone means the request waits for every named approver. A fixed number can keep work moving when someone is away. Choose the rule your approval policy requires.

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 will not save the step, check that both outcome transitions exist.

Who can approve

Controlling the approver list raises common questions: how to restrict the field, how to map approvers by department or by request state, and how to stop requesters hand-picking the approver most likely to say yes.

If requesters must not choose their own approver, hide the Approvers field and map a controlled form choice to the authorised approver. 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.

That deeper piece is now live on Atlassian Community: Who Can Approve in JSM: Restricting and Mapping Approvers — including the team-managed vs company-managed differences the recipe above glosses over.

What approvers actually experience

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

An approval email lets the recipient approve or decline the request. If it arrives while someone is away or gets lost in their inbox, the request can remain unanswered. The team needs a way to check what is still waiting and follow up.

A missed email is one reason approvals can sit for weeks. The follow-up options differ enough that we gave them their own post: When a Jira approval email is missed: ways to follow up. The reminder feature request is tracked in JSDCLOUD-8369.

Approvers can also respond in the portal under My approvals. Admins can view pending approvals for each project.

Approvers who are not agents do not need an agent licence. Approving is a customer-permission action, so someone who signs off a few requests a month does not use an agent seat. That makes approval workflows cost-effective to build properly rather than route 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.

A full episode on group approvals — the counting semantics, the notification gaps, and the API's per-person pending list — is here: Group Approvals in JSM: Where the Pending List Actually Lives.

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 common reasons approvals stall. 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 repairs the approver source. If the repair means re-entering the approval status, or removing and re-adding an approver group, the step runs a fresh round — and decisions already made on the old round stop counting. For edits to the Approvers user picker itself, no reset is documented.
3. The wrong approver was set in the first place. Same manual fix, same caveat.
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.

The deeper version of this section — exact setup steps, the updated-field gotcha, and where each option stops working — is now its own guide on Atlassian Community: How to Remind JSM Approvers Automatically: Every Option Compared.

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, plus Advanced absence cover: when a named approver stays pending past a threshold you set, or their Atlassian account is deactivated, a stand-in you configure is added as an additional approver. It never transfers anyone's identity, authority or decision, and it stops the moment somebody answers. 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

For more detail, follow the linked guides on reminder options, approver selection and group approvals. The guide is refreshed when Atlassian ships approval changes.

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