Approval Gate for Jira — Documentation

Last updated: 19 August 2026.

Approval Gate adds a lightweight approval workflow to any Jira issue: request a sign-off, pick the approvers, and let them approve or reject in a panel on the issue — with an append-only audit trail of who decided what, and when.

Requirements

Jira Cloud. The app is a Forge app and runs on Atlassian's infrastructure.
A site administrator installs the app. After that, any user who can view the issue can open the panel; the app acts with the permissions granted at install (read:jira-work, write:jira-work, read:jira-user).
No account, licence key or external service is needed.

Installation

Install from the Atlassian Marketplace, or from inside Jira via Settings → Apps → Explore more apps (search for "Approval Gate"). Installed apps are managed under Settings → Apps → Manage apps, where you can also review the requested permissions or uninstall.

Where to find it

Approval Gate registers a Jira issue panel. Open any issue and look for the panel titled Approval Gate in the issue view. There is no separate admin screen and no global page — everything happens on the issue.

Using Approval Gate

Create a request. In the panel, fill in "What needs approval?" (required), optionally add details, and pick one or more approvers with the user picker.
Pick the decision rule. With more than one approver you choose between One approval is enough and Everyone must approve. With a single approver the rule is implicit.
Approve or reject. Only the assigned approvers can use the Approve and Reject buttons — this is enforced by the app, not just hidden in the interface. Anyone who may comment on the issue in Jira may add a comment here. A single rejection puts the request into the REJECTED state.
Cancel or reassign. While a request is still pending, the person who created it can cancel it, or swap the approver list. On reassignment the required number of approvals is recalculated for the new list, and approvals already cast by approvers who are still assigned keep counting.
Follow the trail. Every creation, approval, rejection, comment, reassignment and cancellation is appended to the request with the actor and a timestamp, and is also mirrored as a comment on the issue so it shows up in the normal issue timeline.

Approval data is stored on the issue itself as a Jira issue property, so it travels with the issue and is deleted when the issue is deleted.

Blocking a transition

Approval Gate ships a workflow validator. Add it to the transition that must not happen without sign-off, and Jira will refuse that transition until the work item has a valid approval.

Go to Project settings → Workflows and edit the workflow.
Select the transition you want to gate, for example In Progress → Done.
Add a validator and choose Approval Gate — require approval.
Publish the draft.

This works in both company-managed and team-managed projects, on every Jira plan. When the transition is refused, the reason is shown on the transition screen: no approval requested yet, still waiting for approvers, rejected, or approved for an earlier version.

Approvals are tied to a version

An approval is only meaningful for the thing that was approved. Every decision records a fingerprint of the work item’s scope at that moment — summary, description, type, priority, labels, components, fix versions, due date and parent.

If any of those change afterwards, the approval is marked Out of date in the panel and the gate blocks the transition again until someone approves the new version. Comments, worklog, status changes and a change of assignee are deliberately not part of the scope: adding a comment must never invalidate a sign-off.

When the gate cannot be enforced

If the app cannot establish whether an approval exists — an expired subscription, a Jira API failure, or an unexpected error — the transition is allowed through rather than blocked. A gate that froze every transition whenever something went wrong would be worse than one that stops gating.

Those moments are never silent. Each one is recorded on the work item and shown in the panel under Times the gate could not be enforced, with the reason and the time, so an audit shows the exception instead of an unexplained gap.

Limitations

Approvals are per issue. There is no cross-project dashboard or report of open approvals.
No e-mail, Slack or in-product notifications are sent. Approvers learn about a request through the issue comment the app posts, or because you tell them.
No reminders, deadlines, escalation or automatic expiry — nothing runs on a schedule.
Approval status is not written to a Jira field and is not searchable in JQL; it is visible in the panel and in the mirrored issue comments.
Blocking a transition is opt-in: it only happens on transitions where a Jira admin has added the Approval Gate validator. On every other transition the app records the decision without enforcing it.
Only the original requester can cancel or reassign a request, and only while it is pending. Requests that are approved, rejected or cancelled are final and cannot be reopened.
The panel refreshes when it loads or after your own action; it does not live-update when a colleague decides in parallel.

Support

Questions, bugs or feature requests: info@kyc-checks.nl.