Group Approvals in JSM: Where the Pending List Actually Lives

[#1]

Disclosure: I build an approvals app for JSM. Nothing in this guide needs it — everything below is native behaviour.

The complete guide gives group approvals a short section: set a group as the approver source and two behaviours surprise admins — members are notified individually, and the view of who has already approved is limited. Those two sentences deserve an episode of their own, because underneath them sit a counting rule the configuration screen never states, notification gaps Atlassian tracks openly, and a pending list that does exist — one layer below the UI.

How a group approval counts

The shipped source field is Approver groups — a group picker (multiple groups). One naming trap first: the change-management doc tells you to select "Group approvals" as the approval field, but the custom-field type you actually attach is the group picker. If you're hunting the field list for something called "Group approvals", that's why you can't find it.

The interesting part is what "how many must approve" means once groups are involved. The approval step stores its configuration as workflow properties, and one of them — approval.condition.type — carries the semantics. The properties KB gives three values: number (a specific number of people, for user-picker sources), percent, and numberPerPrincipal, "when a specific number of people from each group should approve". That last value is the one the configuration screen never explains: with a group source, the count is per group, not across the pool. Two groups with "1 must approve" means one approval from each. And "everyone" means everyone in every group — an error-message KB spells it out verbatim. A correction is owed here: the previous episode said the step "doesn't understand sets". At the property layer it does, and I've amended that line there.

Two hard edges before you lean on this. The same KB warns that "Existing approval properties cannot be edited or deleted once set" — the semantics are fixed at configuration time. And the per-group counting has an open bug, JSDCLOUD-10451: with "1 per group" configured, Jira keeps asking the remaining members of a group whose quota is already satisfied. Atlassian's workaround field reads "There is no workaround at this time." Declines, meanwhile, have no threshold at all — a single decline ends the step, and the request to change that (JSDCLOUD-4223) sits Under Consideration.

Who actually gets told

Notification is individual. Each member of each group gets the approval email; there is no group-inbox concept. From there it thins out:

• Chat doesn't fire. Slack and Teams approval messages don't go out for group-sourced approvals — Atlassian's own words on JSDCLOUD-12474: "chat is not able to send the approval notifications when customers use approver groups (and not approvers) due to API limitations".
• Customer notifications can't target the group. The "Approval required" customer notification offers Approvers, Reporter and Customers Involved as recipients — there is no approver-groups option in the list. The accepted answer on this thread (Marc from Devoteam) lands on the same point: the notification follows the populated field, and there is no separate customer notification for approver groups. The notification docs themselves only ever say "Approver field" — how each rule applies to people pulled in through Approver groups is simply not stated anywhere.

What each surface shows

The gap is narrower than "the UI shows nothing". In the agent view, the approvals panel does render group state — admins in this thread report it showing the groups and the approvals within each. What is actually missing:

• The portal shows arithmetic, not people. Customers see "Waiting for 1 approval" — a count. Which names are still pending is not listed; that is JSDCLOUD-10260, open since 2021 with 74 votes, workaround "N/A".
• Group approvers lose their name. When the decision came from a group member, the portal shows "approved" without the approving user — with an individual Approvers entry the name appears (JSDCLOUD-16354). Its 2026 sibling JSDCLOUD-18288 adds a worse variant: the portal listing the wrong names against group approvals. Atlassian's note on it: the core approval functionality is not impacted. True — and no comfort to whoever audits the portal record.
• Nothing crosses requests. There is no native view of "every approval waiting on this person". Decisions aren't stored in a searchable field either — JSDCLOUD-4532 has asked for exactly that since 2016 (91 votes). When someone asked how to see approval steps on a board or dashboard, every accepted answer was a Marketplace app.

Where the pending list actually lives

The per-person state exists — one layer down. GET /rest/servicedeskapi/request/{issueIdOrKey}/approval returns, for each approval, an approvers array where every entry carries the user and an approverDecision: approved, declined or pending. The API docs say it plainly: use this to determine the status of an approval and the list of approvers. Permission needed: viewing the request. This is the list the portal won't show you.

Three catches, so you don't over-trust it:

1. The API flattens groups. An approver entry has exactly two properties — the user and the decision. No group field. Every member of every group appears as a plain approver, and after a colleague satisfies their group's quota, the rest of that group still read pending. An admin on this thread pasted the response body and described it exactly: members listed individually, no association to their groups, finalDecision still pending after one group's requirement was met.
2. The threshold is missing. The response doesn't include the number of approvals still needed — that was JSDCLOUD-11905, closed for low engagement. So the portal knows how many and the API knows who, and neither surface alone gives you both.
3. Automation hits the same wall, with an extra ceiling. The same per-approver state exists as smart values, and Atlassian's own KB recipe for nudging pending approvers works by hardcoding index positions — an If/Else branch per approver slot, including its group-picker case. Honest reading: it works when the approver count is fixed and known, and not otherwise. On the query side, "Approvals[Approvals]" = pending() finds requests waiting on a person, but pending() can't take a group (JSDCLOUD-15383). And the reminder email Jira itself sends has a known counting flaw — with two approvers, tickets one of them already decided still appear in the pending list (JSDCLOUD-14352, 87 votes).

When the group changes mid-approval

The sharpest failures are not display problems. They happen when the people or the configuration move while an approval is in flight:

• Membership churn can strand the request. Remove a group member while "everyone must approve" is waiting on them and the request can stick in Submitting Approval — a documented Cloud failure whose documented fix is to add back the same number of users and have them decide.
• Config edits don't warn you. Change the approval configuration — say "everyone" to "one of" — while requests already sit in the approval status, and decisions get recorded without the transition ever firing. No warning appears at edit time (JSDCLOUD-18411). Pair that with "properties cannot be edited once set" above and the safe reading is: treat approval configuration as frozen while anything is in flight.
• Repairs re-run the round. Atlassian's Cloud workarounds for stuck approvals (JSDCLOUD-14294) are to transition out of the approval status and back, or to remove and re-add the approver group — both reset the round and start fresh. Note the precision: for edits to the Approvers user-picker field itself, no reset is documented. Earlier rounds' decisions survive in the issue history tab; getting them out is an export problem (JSDCLOUD-6511, In Progress).

The working model, then: counting is per group and frozen at configuration time; email is the only channel that reliably reaches every member; the agent panel shows state, the portal shows arithmetic, and the API shows people — one short of a complete picture each. And the moment a group or a configuration changes mid-flight, you are in the failure catalogue, not the docs. The complete guide links every episode as it lands.