How to add an approval step to a Jira (Software) workflow

If you work in Jira Service Management, approvals are built in — a request can require sign-off before it proceeds. If your work lives in a Jira Software project (most engineering, ops and internal teams), it depends on your plan: Free and Standard still have no native approval step at all. Premium and Enterprise got one, but it has real gaps. Here’s how to actually require sign-off in Jira Software, on any plan.

What native Jira Software actually gives you

• Free or Standard: a status + a restricted transition. Add an Awaiting approval status and configure the transition out of it so only certain people (a role, a group) can make it. The catch: a transition only records that someone moved the issue — not an explicit approve or reject, who decided, or why.
• Premium or Enterprise: a real approval step, with documented gaps. Jira added an actual approval step to the workflow: a named approver or group must approve or decline before the issue can move. It’s a genuine step up from a bare status — but it has real limits: no role-based approvers (you pick individual people or groups, not “anyone with the Reviewer role”), it bypasses your workflow’s validators and conditions on that transition, and it can’t route to a different approver based on a field’s value.
• Automation for Jira. You can bolt on rules — notify an approver, block a transition until a field is set. It helps automate around the gap, but the decision record still has to come from somewhere else.

For an informal “someone with the right role moves it along,” the restricted-transition approach is fine on any plan. The moment you need an auditable decision that doesn’t trip over those gaps — or you’re not on Premium at all — the native tools fall short.

What a real approval step needs

An approval that stands up to a later “who approved this, and why?” needs three things the status-only approach doesn’t give you:

1. A clear request for approval on the issue.
2. An explicit approve or reject, by a named approver.
3. A recorded decision — the outcome, the person, the timestamp, and optionally a comment — kept on the issue.

The lightweight-approvals-app way

This is exactly what Signet adds to plain Jira: request approval on an issue, have the approver approve or reject, and record the decision on the issue — on any plan, without Jira Service Management, a Premium upgrade, or a workflow rebuild.

Why that’s worth it even above a status workaround:

• A real decision, not just a move — approve/reject by a named person, with the reason, visible on the issue.
• Works on any plan — Free or Standard, not just Premium or Enterprise, and without moving work into JSM.
• No workflow edit, no admin rights — nothing to configure in the workflow itself.
• A record for later — the decision is there when an audit or a “who signed off on this?” question comes up.

Which should you use?

• In Jira Service Management? Use the native approvals — they’re built for it.
• In Jira Software and a restricted transition is enough? The Awaiting-approval status pattern works for informal sign-off, on any plan.
• On Premium or Enterprise and the native approval step’s gaps don’t matter for your case? It’s already there — use it.
• Need an auditable approve/reject decision without those gaps, or you’re not on Premium? That’s what a lightweight approvals app like Signet fills, on any plan — compare the best Jira approval apps, and see how to record who approved an issue.