Docs

Approvals & intake

Asking people to approve an issue, how decision rules work, deciding on your own approvals, and the intake queue where requests are triaged before they become issues.

Approvals

An approval asks one or more people to say yes or no to an issue — a change, a purchase, a release. It works on normal issues and on service desk requests.

Asking for approval

  1. Open the issue and press Request approval (the Approvals section).
  2. Choose a template (set up by a project administrator, below) or pick approvers yourself.
  3. Confirm. Approvers are told by e-mail; the approval shows on the issue as pending.

The set of approvers is fixed when the approval is created — later group changes do not affect it — and you can never approve your own request: the requester is removed from the approvers. Press Cancel approval to withdraw a pending request.

Deciding

Your work → My approvals lists everything waiting for your decision. Open one, read the issue, and choose Approve or Decline with an optional comment. A decision cannot be changed afterwards. Service desk customers can be approvers too and decide from the portal.

Decision rules

RuleApproved whenDeclined when
All must approveeveryone approvedanyone declined
Any one approverone approvedeveryone declined
A number of approvers (n)n approvedn can no longer be reached
A percentage of approversthat share approvedthat share can no longer be reached

An approval ends as soon as its outcome is certain, so you do not wait for the rest. Outcomes are approved, declined, cancelled or expired.

Templates (project administrators)

Under Project settings → Approval templates define a template: name, approver users and groups, decision rule, optional auto-approve / auto-decline conditions on priority or issue type, a reminder interval, an expiry, and optional follow-up transitions. Reminders go to approvers who have not decided; an approval that outlives its expiry becomes expired.

In the workflow designer a transition can require an approved approval (it stays visible but explains why it cannot run) and can request one when it runs.

Intake

Intake gives a project an inbox for incoming requests and ideas. A submission is not an issue until a team member accepts it, so backlogs and boards stay clean. It suits software and business projects; customer help with SLAs belongs in a service desk.

Switching it on

A project administrator opens Project settings → Intake and enables the queue; optionally also the public form and e-mail intake. The queue is under Projects → Intake.

How requests arrive

  • In the app — Submit to intake in the queue. Anyone who can browse the project may submit.
  • Public form — an unguessable link anyone can open without an account. Choose its title, introduction and whether name, e-mail and description are not asked, optional or required. It has spam protection and size limits.
  • E-mail — an inbound mail gateway posts messages to a secured address.
  • API — the same endpoint with an access token.

Triage

People who can create issues work the queue. Tabs show Pending, Snoozed, Accepted, Declined and Duplicate with counts. For each item:

  • Accept — creates a real issue: choose the issue type (required), priority and assignee, edit the summary and add a note.
  • Decline — with an optional reason.
  • Snooze until a date (up to a year); it comes back to Pending by itself.
  • Duplicate of an existing issue (give its key).
  • Reopen a declined, duplicate or snoozed item. Accepted items are final.
  • Bulk — up to 100 items at once; each is reported separately.

Keyboard: j/k or arrows move, Space selects, a accept, d decline, s snooze, u duplicate. If the requester gave an e-mail address, they are told when their request is accepted or declined. Attachments on intake items are not supported yet.