Disclosure: I build Approval Nudge at Quietmill, the app discussed in the second half of this article.
A JSM request says Waiting for 2 approvals. The approver source is a group. That sounds clear until the request stalls and an admin asks the question that matters: which two people are still expected to answer?
The group name is not the answer. One member may already have approved. Another may be away. A third may have missed Jira's original email. On a busy service desk, finding that out becomes a small daily ritual: open the request, inspect the approval, compare the people, send the chase, repeat.
Versions 3.15 and 3.16 of Approval Nudge were built to remove that ritual. The first made group-backed approvals visible to the app. The second added a safe follow-up email for the people still waiting.
Jira uses the group to decide who may approve, but each member answers as an individual. That distinction is easy to miss because Jira's surfaces split the useful information: one place shows the group or the number required, while the request API exposes each person's decision.
The earlier group-approvals episode explains the counting rules and the API in detail. The practical admin question is simpler:
Do not remind “the group”. Remind the people in that group who still need to answer.
That is harder than a scheduled comment. A scheduled app must be able to read the current decision for each member, stop after the approval moves, and refuse to send when Jira does not provide a complete recipient list.
Approval Nudge 3.15 added group-backed approval discovery to both Standard and Advanced. A project admin opens the project's Approval Nudge settings and saves the enabled configuration once. Scheduled scans can then read the approval details that admin is already allowed to see.
The access is deliberately narrow. Approval Nudge can read the current decisions; it cannot approve a request, edit the approval group or add and remove group members. If the saved admin later loses access, the app stops using that reader rather than guessing.
From the next scan, group-backed approvals appear in the same Overview as approvals that use the Approvers field. There is no separate report to maintain and no hardcoded list of group members.
Advanced projects now have a separate Approver groups panel. Turn on Email people who haven't approved and the normal reminder schedule also covers group-backed steps.
The group-email setting is separate, explicit and off for existing projects until an admin enables it.
The setting is intentionally separate from Jira's approval-email resend. The two approval sources need different behaviour:
To the approver, both messages mean “this approval still needs you”. To the admin, the distinction matters. The group reminder does not pretend to be Jira's original email and does not alter the group to force another native notification.
Before every group email, Approval Nudge checks the current approval again. It sends only when every decision is still pending, only to active accounts, and never to more than 20 people in one approval. If Jira cannot confirm the complete recipient list, the app sends nothing and records the reason.
The first approval or decline ends the group-email path for that approval cycle. No one receives another group reminder after somebody has answered.
The request panel records both the normal reminder and the email action, so an agent can see what happened without searching notification logs.
The request shows who is still pending, when the reminder ran and when Jira sent the follow-up email.
The Approvals Overview is where the time saving becomes obvious. It shows waiting approvals across the projects an admin manages, including the people still pending, the age of the approval and the last reminder.
Individual and group-backed approvals appear together. The admin can see the pending person and reminder history without opening every request.
This also helps with planned leave. For an approval that uses the Approvers field, Advanced can add the chosen stand-in as an additional approver. For a group-backed step, Jira does not offer a safe request-only substitute. The Overview therefore tells the admin whether the planned stand-in is already allowed to approve through that group.
It checks readiness; it never changes group membership. If the stand-in is not eligible, the Jira admin can make that decision before the leave begins, with the full site-wide effect visible.
Version 3.15 added group discovery and a JQL-selected alternate reminder schedule. Version 3.16 added the Jira-hosted group reminder, group cover-readiness checks and clearer panels across all three settings tabs.
Together, they close the gap between “this request needs approvals from a group” and “these are the people an admin needs to help right now”. Approval Nudge is available on the Atlassian Marketplace for JSM Cloud.
How does your service desk handle a group approval when one member goes away or misses the original email? I would be interested to hear where the manual work still sits.
Shreyas_Quietmill
0 comments