Approvals

When to use

When work has to pause for a human gate. Distinct from confirms (12e, blocking and sync) — approvals are out-of-band, batched, and may carry a reviewer queue that the requester can see status of but not skip.

Approval queue

List of pending items, most-urgent first. Each row carries the requester avatar + title + amount/scope + age + a pair of approve/reject buttons. Bulk select for batch approve.

Approval detail

The single-item review surface. Header carries the request title + status + reviewer chain. Body shows the request data (line items / diff / metadata). Footer is a primary Approve, a secondary Reject, and a "Request changes" path for fixable issues.

Composition rules

• Approve is primary, not destructive — even when approval has financial weight, the reviewer's main job is to approve eligible items. Reject is the secondary action; type-to-confirm is reserved for irreversible terminal states (deny + lock).
• "Request changes" lives in the footer too — most rejected requests can be fixed and re-submitted. Surfacing the third path keeps the reviewer from forcing a binary outcome on a fixable issue.
• Show the reviewer chain — "You → CFO → CEO" sets the right expectation: this approval isn't terminal. Without the chain, requesters chase ghosts.
• Bulk approve only for low-stakes items — "Approve all" should be ghost-styled, not primary. The default is one-by-one because the queue is curated; if it isn't, fix the upstream policy.
• Pending status uses warning, not info — pending blocks downstream work. The queue should look like work, not a passive list.

See also

• list-ui · list-item-ui — queue row anatomy.
• description-list-ui — request metadata layout.
• tag-ui — pending / approved / rejected status tags.
• permissions-sharing — adjacent pattern (access requests as a sub-flavor of approvals, see 33f).
• bulk-action-toolbar — shared row-selection affordance for batched approvals.