A Jira feature request, JSDCLOUD-8369, asks Atlassian to remind approvers when a service-desk request is waiting on them. It dates from 2018.
An approval request can sit unanswered because its email arrived while someone was away or was lost in a busy inbox. The requester is waiting, and the team has to decide how to follow up.
Why this gap exists
Approvals in JSM are a workflow feature, and notifications are a platform feature. The approval step sends its notification once, when the request enters the status. There is no built-in “still pending after N days” reminder, so you add one with a scheduled automation rule or a separate tool.
The automation workaround — and its real costs
A scheduled Automation rule may be enough. Check how it selects recipients, limits reminders and handles requests that have already moved on. Teams who run one discover its limits one by one:
- It may not know who is pending. The rule cannot easily tell which approvers have already answered on a multi-approver request, so it may nag everyone or a hardcoded someone.
- Its message has no buttons. Jira's real approval email carries one-click Approve/Decline. The automation's comment or email doesn't — the approver still has to find their way in.
- It needs explicit stop conditions. A basic rule has no built-in reminder counter or escalation path unless you build them, and someone then has to maintain them.
- It needs maintenance across projects. A shared automation rule can cover several projects, but you still need to maintain its scope, filters and permissions. Atlassian explains the available scopes.
- It may not notice inactive approvers. If an approver's account was deactivated, a basic rule can keep reminding that account.
We've since written the full option-by-option version of this — the manual filter, this rule with its exact JQL, approver-side habits, and where each one stops working — as an implementation guide on Atlassian Community: How to Remind JSM Approvers Automatically: Every Option Compared.
What a real fix looks like
Whatever you use — automation, an app, or a human with a spreadsheet — a complete answer to stuck approvals has five properties. It targets only the approvers who haven't answered. It can re-deliver the actual approval email, buttons included. It stops when someone acts and caps how often it nags. It escalates to a named human when polite reminding fails. And it notices when an approver can no longer answer at all — the deactivated-account case that quietly kills approvals in every growing company.
Full disclosure: we build Approval Nudge, a small Forge app that covers this list — targeted reminders, native approval-email resend, escalation and inactive-approver detection. An Advanced edition adds absence cover: a stand-in you configure joins as an additional approver when someone stays pending past your threshold or their account is deactivated. It runs entirely on Atlassian's infrastructure. Standard is free at Atlassian's up-to-10-user app tier; see the Standard and Advanced plans on Atlassian Marketplace. If the automation rule serves you well, you don't need it.
Where this series goes next
Another recurring question is who should be allowed to approve. That guide is live on Atlassian Community: Who Can Approve in JSM: Restricting and Mapping Approvers. It has nothing to do with our app; it is just the guide we wished existed.
Questions about a stuck-approval situation we didn't cover? Tell us about it — the interesting gaps become posts, and occasionally products.