How to record who approved a Jira issue (and keep the decision)

Six months after a release, someone asks: “who approved shipping this?” You open the issue, and all you have is a status that once read Approved and a history line saying so-and-so moved it. That’s not really an answer — it doesn’t say the person decided anything, whether they approved or objected, or why. Jira only records a real approval decision if you’re on Premium or Enterprise and someone set up the native approval step; on Free or Standard, or with the common status-plus-transition workaround, recording one is on you. Here’s how to make an approval that actually holds up, on any plan.

What Jira records natively (and what it doesn’t)

It depends on your plan and setup.

The common pattern on Free and Standard: an Approved status plus a restricted transition. It gets you something — the issue history shows who moved the issue to Approved and when. But it stops well short of a decision record:

• No approve-versus-reject. A transition only captures the move that happened. A rejection is just a different transition, not part of the same recorded decision.
• No reason, by default. There’s nowhere in a bare transition that says why it was approved.
• It doesn’t read as a sign-off. “User X transitioned the issue” is not the same as “user X approved this, on this date, for this reason.” One is a side effect; the other is a decision.

On Premium or Enterprise, if an admin set up the native approval step: it does capture a real decision — a named approver, an explicit approve or decline, and optional feedback. That’s a genuine improvement over the status workaround. The catch is what it takes to get there: it’s gated to Premium and Enterprise, someone with admin rights has to configure it on the workflow, approvers can only be named people or groups (not a role), and the approval transition bypasses your workflow’s validators and conditions.

So the native record answers “who decided, and what” reasonably well — but only on the right plan, with the right setup, and with those limits attached.

Capturing the actual decision

If you’re not on Premium or Enterprise, or no one has wired up the native approval step, you need another way to get the decision itself recorded — the approver, approve or reject, the timestamp, and a reason. Signet adds exactly that to plain Jira: request approval on an issue, have a named approver approve or reject, and keep the decision on the issue — on any plan, without Jira Service Management, a Premium upgrade, or a workflow rebuild.

Why that’s worth it over a bare status:

• A decision, not a move — approve or reject by a named person, with the reason, recorded as data on the issue.
• Works on any plan — no Premium or Enterprise required, and no admin rights or workflow edit to set it up.
• A record you can point to — when the “who signed off?” question comes months later, the answer is on the issue, not inferred from a transition.
• Reviewable — decisions captured as data, alongside a durable change history, are something you can actually audit across issues.

If you also need the surrounding change trail — who touched the issue before and after the approval — that’s the audit-trail side of the same problem; see audit log vs issue history. And for standing up the approval step itself, see how to add an approval step to a Jira workflow.

Which should you use?

• Informal sign-off where “someone with the right role moved it” is enough? The restricted-transition status pattern works, on any plan.
• On Premium or Enterprise, with the native approval step already set up, and its limits don’t matter for your case? Use it — the decision is already recorded.
• Need to answer “who approved this, and why?” later, on any plan, without the setup or the limits? Record the decision itself with an approvals app like Signet.