Why approvals in Jira so often end up in a comment — and what that costs

[#1]

I work at Ballon Apps, where we build apps for Jira — including the one I mention at the end of this post. This is about a pattern I run into at almost every team, and that we ran into ourselves before we built anything for it.

The pattern. An issue needs to be approved before it can move on. Jira has no field for that, so it happens in a comment: "approved from my side". That works fine — until three months later you have to show who approved what, when, and whether that was before or after the last change to the scope.

Where it goes wrong, in order of how often I see it:

1. The approval belongs to an older version. Someone approves, the scope then changes, and the approval stays there as if nothing happened.

2. One approver where there should have been two. Nobody notices, because there is nowhere that records how many were required.

3. The approver wasn't entitled to approve. That only surfaces during an audit.

What you can do without an app, and how far that gets you. A status field plus a workflow validator covers point 3 fairly well: you can restrict a transition to a role. Points 1 and 2 are possible with a custom field per approver and a scripted condition, but then you maintain a small script per project. For two projects that is fine; at twenty it is not.

Where we ended up. We built Approval Gate for Jira because we couldn't keep that third step up ourselves: multi-approver with an audit trail that records who approved, when, and against which version. It is on the Marketplace and there is a free tier:

https://marketplace.atlassian.com/apps/21996072/approval-gate-for-jira

What I am looking for. The app is new and has almost no users outside ourselves. I would like to find a few Jira admins willing to try it in a real environment and tell me honestly where it falls short — in particular whether the audit trail actually shows what you need to demonstrate during an audit. Reply below if you are up for that and I will get in touch.

I am also genuinely curious how others solve this without an app. If there is a clean workflow-only approach I am missing, I would like to hear it.

[Mohammed AlMunsif _ARRIBATT_]

Hi @Ballon Apps ,

Since you asked for honest feedback, here is mine:

The statement "Jira has no field for that" is only partially correct. Jira actually includes an approval feature out of the box. It is available in JSM across all tiers, as well as in Jira Premium and Enterprise.

Because of this, most teams will likely turn to the native OOB features instead.

[Ballon Apps]

To be precise about where that feature lives: in Jira Service Management approvals are available on all plans, and approvers don't even need a JSM licence. In Jira Software and Jira Work Management they're Premium and Enterprise only, and only in company-managed projects — team-managed projects don't have them on any plan.

The built-in feature is also more capable than a one-line comparison suggests: it can require a specific number of approvers rather than just one-or-everyone, it can exclude people from approving so a reporter can't sign off their own request, and it controls which status the item moves to on approve and on decline.

On the enforcement point: my app does now block the transition — there's a workflow validator you attach to the transition that must not happen without sign-off, and it works in company-managed and team-managed projects on any plan. Two honest caveats: it's opt-in per transition, so on any transition where an admin hasn't added it the app still only records the decision without enforcing it; and it's built on a Forge module that Atlassian still labels preview, so the contract can change.

The one thing it does that I haven't found in the built-in feature: an approval is tied to the version of the item it was given for. If the summary, description, issue type, priority, labels, components, fix versions, due date or parent change afterwards, the approval is marked out of date and the gate stops honouring it. Comments, worklog, status and assignee deliberately don't count — a comment shouldn't invalidate a sign-off.

Two of the gaps you'd have found are closing but aren't released yet, so I'll flag them as what they are: a quorum rule ("2 of these 5 must approve") and excluding people from approving — by default the person who raised the request can't sign it off themselves, plus a named exclusion list. Both are built and tested, neither is deployed or tested in a live Jira, and the exclusion is set per request rather than enforced centrally by an admin the way the built-in one is. I'd rather say that than let it read as shipped.

Where I think it earns its place is Free and Standard, and team-managed projects on any plan, because the built-in approvals simply aren't there. It also doesn't need a site admin: no custom fields, no workflow editing, no publishing a draft. And it isn't tied to a status — you can request sign-off on any issue at any point, more than once, which is awkward to model as a workflow step.

So: if you're on Premium or in JSM, and your approvals map cleanly onto a workflow status, use the built-in one. It's there and it's included. If you're on Standard or in a team-managed project, that option doesn't exist, and that's the gap I was trying to fill.

Fair challenge either way — it's pushed the app somewhere better.