Documentation

Approval Flow for Jira

Approval Flow adds required sign-offs to Jira work items and enforces them in your workflow. You list the approvals a work item needs; a workflow validator blocks the transition until every required sign-off has been granted. Each sign-off records who approved and when.

Approval Flow is an Atlassian Forge app published by Stanki Guild sp. z o.o. It is built for Jira Software and Jira business projects (not Jira Service Management) and runs entirely on Atlassian's platform.

1. A Jira site administrator installs Approval Flow from the Atlassian Marketplace.
2. During installation the administrator approves the permissions listed under Permissions and why we need them.
3. To enforce sign-offs, a Jira administrator adds the validator Approval sign-off required to the workflow transitions that should be gated (see Block a transition until sign-off).
4. Billing, trials and licences are handled by Atlassian. See Editions.

Sign-off requirements

In the panel, type one or more requirements, one per line (for example "QA lead sign-off"), and click Add. You can also add section headers to group requirements, reorder entries with the arrow buttons, edit text, and remove entries. If the work item has no requirements yet, Add a sample sign-off policy adds a ready-made release sign-off set.

• Required: mark a requirement as required for the approval gate. If any requirement on a work item is marked Required, the gate checks only the Required ones; otherwise it checks all of them.
• Editing a requirement's text clears its existing sign-offs and rejections, so an approval always refers to the text that was approved.
• Requirement text is limited to 500 characters.

Approve, revoke and reject

• Approve records a sign-off receipt with your Atlassian account and the time. The panel shows the approver's name, avatar and date.
• You can revoke your own sign-off.
• Reject requires a reason. A rejection blocks the requirement until someone approves it again; the rejection stays in the history.

Your identity is always taken from Jira's trusted context, never from what the browser sends, so nobody can sign off as someone else.

Who can approve

• Open requirement: anyone who can see the work item can approve.
• Named approvers: choose up to 20 people per requirement with Assign approvers. Only they can approve or reject it.
• Approver groups and project roles (paid): enter Jira group names or project role names, comma-separated. The names are checked when you save. Membership is checked live at the moment someone approves; it is never copied into the requirement. If Jira cannot answer the membership question, the sign-off is refused rather than guessed. Receipts show "via group" or "via role".

Quorum (N of M)

Each requirement can require more than one distinct approver, from 1 to 10. The panel shows "k of N sign-offs". If the named approvers are too few to ever meet the quorum, the panel warns you.

Separation of duties

Turn on Separation of duties (no self-approve) for a work item and two rules apply:

• The person who created a requirement (including by applying a policy or the sample) cannot approve it.
• At the transition, a person who is the only approver of a gating requirement cannot perform the transition themselves.

Out-of-office substitute

In the panel, My out-of-office substitute lets you name one substitute and a date range (From and Until, whole days in UTC, inclusive). While it is active, your substitute can approve or reject on your behalf on requirements where you are a named approver. The receipt records both people ("X on behalf of Y") and counts as your sign-off for quorum and separation of duties. Only you can set or clear your own substitute.

Waiting time

Each pending requirement shows how long it has been waiting ("Waiting N d"). Past a threshold set by an administrator (default 7 days) it is flagged in the panel and on the Approval health page. This is display only: the app sends no reminders, emails or notifications.

Block a transition until sign-off

A Jira administrator adds the Approval sign-off required validator to a workflow transition. When someone attempts that transition:

• If required sign-offs are still open, the transition is blocked with a message such as "Approval not complete: 2 required sign-offs still open (1 rejected)."
• With separation of duties on, the sole approver of a gating requirement is blocked from performing the transition.
• A work item with no requirements is never blocked.
• If the check itself cannot be completed, the transition is blocked (fail closed) and the user is asked to try again.

Approval policies (paid)

Save the current requirements of a work item as a named policy, then apply it to other work items. A policy keeps each requirement's text, its Required flag and its quorum. Policies can be deleted from the panel.

Policy auto-apply by issue type (paid)

On the Approval auto-apply admin page, map an issue type to a policy. When a work item of that type is created, the policy is added to it automatically. This runs after the work item is created and never blocks creation.

Approval health (paid)

The Approval health project page lists the work items in the project that are still awaiting required sign-off, with waiting time and rejection counts.

• Filter by fix version or sprint.
• Export the results as CSV text to copy.
• The search runs with your own Jira permissions, so the report contains only work items you can open.
• At most 200 work items are scanned per view; the page states when there are more.

Governance settings

On the Approval auto-apply admin page, the Governance section has:

• Only project admins may configure requirements: when on, only project administrators of the work item's project can add, edit or remove requirements and sections, set approvers, change quorum or the Required flag, apply policies or the sample, and toggle separation of duties. Approving, rejecting and revoking stay open to every eligible approver. Off by default. Only a Jira administrator can change this setting.
• Waiting-time threshold: the number of days (1 to 365) after which a pending requirement is flagged.

Approval Flow is paid via Atlassian. Without an active paid licence the app keeps working with a reduced feature set.

Where a paid feature is unavailable, the app shows a Start free trial button that opens the Atlassian trial flow.

The app has no write access to Jira data. It never reads work item descriptions or comments. It declares no external network access, so it cannot send data anywhere outside Atlassian.

• All data is stored in Forge hosted storage on your own Atlassian site. Stanki Guild operates no servers and has no access to your data.
• Stored: requirement text, approver account IDs, group and role IDs, sign-off receipts (account ID, time, and the person signed for when a substitute acts), rejection receipts (account ID, time, reason), policies, out-of-office substitutes, the auto-apply map and app settings.
• Not stored: display names (looked up when the panel is shown), email addresses, passwords or tokens.
• Sign-off and rejection receipts are kept as the audit trail until the requirement is deleted in the app.
• On uninstall, the app runs a clean-up that deletes its stored data: every approval record with its receipts, every policy, every substitute, the auto-apply map and the settings. If the clean-up cannot finish, Atlassian holds the remaining data only for its 28-day retention window after uninstall and does not restore it automatically on reinstall; we cannot read it during that time.
• Uninstalling permanently deletes all records. Reinstalling does not bring them back: from the app's point of view the deletion is final. Export first (paid edition).

Full details: Privacy Policy, Security Policy, Data Processing Addendum.

• Documentation and policies: https://stankiguild.com/
• Support: support@stankiguild.com, 09:00-17:00 Monday to Friday, Europe/Warsaw. See Support for response targets and what to include.
• Security issues: security@stankiguild.com
• Privacy and data protection: privacy@stankiguild.com