nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Can Jira stop a version from being released until the right people have signed off?

Bartosz Stankiewicz

Update, 1 Nov: Jim M points out below that Jira now has a "Require approvals before moving to Released" option, which blocks the release until approvers approve. He sees it on Jira Standard in the Create release dialog but not in Edit release, and thinks it is a staged rollout rather than a plan limit. It wasn't on my Jira Free test site, so check what your own site shows. Thanks Jim!

Short answer: not natively on my Jira Free test site, and as far as I can tell not with an app either. I'll say why, and what you can do today.

The request is JRACLOUD-92893, "Add a approvals feature for when releasing versions". It was opened in October 2017. It has 185 votes and the status is In Progress, which it has been for years. The comments read like a list of people who need this for an audit. In 2019 one of them wrote that they have HITRUST requirements to have a documented approval in place for any product release. In January 2024 another described their stop-gap: a standard work item called "Release Approval", created by Automation every time a version is created, to get the workflow and auditing they need. Their own verdict was "Still holes in the stop-gap but it's better than what is currently present."

Native approvals do not fill the gap either. Atlassian's documentation says the approvals feature is only available on Premium editions in Jira, and it is added as a step on a status in a company-managed project's workflow. A version is not a status of a work item.

I also checked whether an app could block the Release button. Forge, the platform our apps run on, has a workflow validator, and it works on work item transitions. Events for versions exist, including one when a version is released, but they fire after the release has happened. I found no hook that runs before it and can say no. I read the Forge events reference and the validator page. I haven't tried every corner of the platform, so tell me if I missed a module.

So the options today.

The Automation stop-gap from that comment. A release work item per version, with its own workflow. It is cheap, and you will see the holes within a release or two: nothing connects the work item to the Release button, and nobody records who signed in a form an auditor can check.

The same idea with a real sign-off on that work item. This is what I do with Approval Flow, which I make, so I am biased. A work item such as "Release 1.4 go or no-go" sits in fix version 1.4. It carries three required sign-offs, each with named approvers, and a validator on its transition refuses to move until all three are in. Every decision goes into a hash-chained audit trail you can export, and the work item has a certificate you can download. On my test site a policy called "Release sign-off" does exactly this on a DEMO project: the transition stays blocked until the third person signs.

What it does not do is stop someone clicking Release on the version page. The sign-off is on the work item, not on the version. If your release manager ignores the work item, nothing stops the release. I want to be plain about that, because "release sign-off" sounds like more than it is.

I have thought about a softer version: a sign-off record per version and a warning when a version is released without one. I have not built it. It would warn and record, never block. Turning a release back to unreleased needs a permission I do not hold, and it is a rude thing for an app to do to someone. I would build the warning only if a few teams said they would use it.

If you release in a regulated setting, how do you prove today who approved version N, and where does that record live?

Comments

Jim M _Cahaba Forge_

Jira now has a native approval gate on releases. It's a "Require approvals before moving to Released" checkbox in the Create Release modal (new enough it still carries a "New" tag in the permission scheme), paired with an Approvers section on the release record.

It has to be turned on at creation time. I couldn't find any way to add it to a release after the fact. I confirmed that by testing: approvers added to a release that was created without the box checked are purely decorative, I could move Stage to Released with an approver still sitting on Pending. But on a release created with the box checked, Jira genuinely refuses the transition and shows an explicit error until every required approval is granted. So it's a real gate, just opt-in at the moment of creation, and apparently permanent either way, you can't turn it on later if you forgot, and (as far as I've found) can't turn it off either.

One more thing worth flagging if you go looking for this: I didn't see this feature everywhere I checked, so it may still be rolling out. Worth checking your own site directly rather than assuming you do or don't have it based on this thread.

Regarding your original question, there are actually two kinds of approval going on with releases.

Gate one: can the release record itself move to Released? As of now, yes, Jira can genuinely enforce this, if you check the box when you create the release.

Gate two: are the issues in the release actually finished, and has the business approved them? Nothing native checks this at all. The approval checkbox doesn't read issue status, an approver could click Approve with every issue still in To Do and nothing would object.

Two ways to close gate two today, neither of them native:

The cheap one is pure process: make your release manager the named approver, and their job is to run one JQL check before they approve, fixVersion = X AND statusCategory != Done, expect zero results. No tooling required, just a habit someone has to actually follow.

The stricter one is to pair it with an app that gates the issue workflow itself, so "Done" can't be reached without a recorded decision in the first place. Full disclosure, I build a similar app (Business Sign-off & Approval for Jira). Each issue carries required sign-offs, and the transition into Done is blocked until they're satisfied. If your release manager can trust Done already means approved, checking "are all issues Done" becomes the same check as "has the business approved everything in this release." One caveat either way: the gate needs to sit on every transition that lands in the Done status category, not just the one literally named Done, some workflows have more than one.

So, short version: gate one is real now, or at least being rolled out, if you remember to turn it on when you create the release. Gate two is still entirely on you.

Regards,

Jim, Cahaba Forge

Victor Tashkov

Disclosure: I'm the developer of Sign for Jira, so weigh this accordingly.

To your closing question, how a regulated team proves who approved version N: @Jim M _Cahaba Forge_ covered the native side. A release created with "Require approvals before moving to Released" checked won't move to Released until its approvers have approved, and the approvers are recorded on the release. That answers "was it approved". Under 21 CFR Part 11 or Annex 11 an auditor usually asks more: what the signer meant by signing, that they re-authenticated at that moment, and whether the record changed afterwards.

That is the part we built Sign for Jira for, on a go/no-go work item in the version, much like your approach. The signer picks a meaning set by the space admin (for example "Approved for release") and confirms with a personal 6-digit PIN on top of the Atlassian login. Signing can be restricted per space to Jira groups and space roles. The signed fields are hashed, so the signature shows Invalid if they change later, and signatures can't be edited or deleted. A workflow validator keeps the go/no-go work item from moving until it is signed, and the Sign custom fields let the release manager find with JQL any work item in the version whose last validation status isn't valid. The record lives on the work item, with audit logs and export to CSV, JSON or print, and it all runs on Atlassian Forge.

It provides the technical controls. The validation, and the procedure that says "no release without a valid signature on the go/no-go item", stay with the team.

Bartosz Stankiewicz

Thanks Jim, that's exactly the kind of correction I hoped for. I checked our test site, which is on Jira Free, and the Create release dialog there has no such checkbox, so it may depend on the plan or still be rolling out. Which plan is your site on? I'll update the article so it doesn't say "not natively" without that caveat.

Jim M _Cahaba Forge_

@Bartosz Stankiewicz - Jira Standard, but I don't see anything in Atlassian's docs that ties this to a specific plan, so I can't confirm tier-gating one way or the other. My guess is this is a staged rollout rather than a plan restriction. I have the approval required check box when creating a release, but do not see the Edit Release modal Atlassian's own docs describe exposing it too: "…unless the 'Require approvals' checkbox is selected in the create or edit Release modal..."

Clicking into an existing version here just opens a release detail page, no modal, no checkbox. If a single feature can land partially even on my site, it'd explain why you're not seeing any of it yet on Free - different accounts picking it up in different stages, not a hard plan cutoff. (either that or the Atlassian docs are just wrong)

Bartosz Stankiewicz

Thanks for checking on Standard, that's useful. So it's there on Standard at creation time and missing from Edit, and our Free test site doesn't have it at all. I'll add that to the update at the top of the article.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira-cloud

compliance

approval-workflow