JSM approvals vs Jira Software approvals — what's the difference?

“Just add an approval step” sounds simple until you hit the fine print: Jira Service Management and Jira Software now both have native approvals, but they’re two different features with different rules — and Jira Software’s only works on Premium or Enterprise, with real gaps even then. Here’s exactly where approvals live, what each version actually does, and what to do if yours doesn’t fit.

Where approvals are native — and where they aren’t

• Jira Service Management: yes, on any plan. JSM has a built-in approval step on request types. A customer’s request can require sign-off before it moves forward, approved or rejected right in the portal. It’s genuinely good — if you’re in a JSM service project.
• Jira Software / Business: yes, but only on Premium or Enterprise. Jira added its own native approval step — a named approver or group approves or declines before a work item can move. It’s a separate feature from JSM’s, doesn’t require a service project, and works in both company-managed and team-managed projects. On Free or Standard, there’s still nothing native at all.
• Even on Premium, it has real gaps. The approver picker only takes named people or groups — there’s no role-based allow-list. The approval transition bypasses your workflow’s validators and conditions. And you can’t route to a different approver based on a field’s value.

So the dividing line used to be “which Jira” — now it’s also “which plan, and do these gaps matter for you.” A JSM approval is tied to a request type in a service project; Jira Software’s is tied to a workflow step and a Premium license, with the limits above.

The usual workarounds (and why they wear thin)

On Free or Standard — or any plan if the native gaps above matter to you — teams improvise:

• A status + a custom field — an “Awaiting approval” status and an “Approved by” field someone fills in. It works until you need to know when, why, or to stop the issue progressing until it’s approved — none of which a status really enforces.
• A comment convention — “approved 👍” in the comments. Fine for a two-person team; useless as an audit record.

Both leak the thing an approval is for: a reliable, reviewable record of who decided what.

The fix: add real sign-off on any plan

Signet adds the same request-approve-record flow to any Jira issue: request a sign-off, approve or reject with a reason, and keep an auditable record of who approved what and when — on any plan, no workflow surgery, no admin rights, no waiting on Premium. See how to add an approval step to a Jira workflow for the step-by-step, and how to record who approved a Jira issue for the audit angle.

The takeaway

Approvals are native to JSM on any plan, and to Jira Software/Business only on Premium or Enterprise, with real gaps even then. If you’re on Free or Standard, or the native gaps don’t work for you, status-plus-field workarounds don’t give you a real record. Add a proper request/approve/record flow on the issue and you get sign-off that holds up, on any plan, without changing how your team works.