Approvals
What requires a second staff member's sign-off, and why.
Some actions are powerful enough that one staff member acting alone isn't
enough — a PendingApproval gets created instead of the action happening
immediately, and it sits until an OWNER or ADMIN reviews it from
/admin/approvals.
This is a "propose now, a higher tier decides later" pattern, not a separate permission system — approving a pending item runs the exact same underlying action a direct click would have, just deferred.
What requires approval, and from whom
| Action | FRONT_DESK | ADMIN | OWNER |
|---|---|---|---|
| Refund | Always needs approval | Only above the configured threshold | Only above the configured threshold |
| Invoice void | Always needs approval | Never | Never |
| Weekend meeting-room booking | Always needs approval | Never | Never |
| Staff invite | Can't reach this at all | Needs OWNER approval | Never |
| Staff role change | Can't reach this at all | Needs OWNER approval | Never |
| Large proposal discount | Needs approval above the configured discount threshold, for any role that can send a proposal |
The refund threshold and the proposal-discount threshold are both owner-editable settings — see Approval Rules.
A few things worth knowing
- The gate lives at the action, not the money. A refund issued through the explicit "Issue refund" button is gated. A refund that happens as a side effect of something else — like rescheduling a booking down to a cheaper slot — is also gated, using a hold-and-alert pattern instead of a formal pending approval, since that path can touch multiple payments at once and has no staff member to "propose" it when a customer does it themselves from the portal. Either way, a refund above threshold never fires silently.
- Approving doesn't require re-entering details. The original request — amount, reason, the booking or invoice in question — is preserved exactly as proposed. An approver confirms or rejects; they don't redo the work.
- Rejecting an approval isn't the same as it never happening. A rejected refund, void, or booking leaves an audit trail same as an approved one — see Reporting and the audit log.
- This is unrelated to Clerk roles or page-level permissions. A FRONT_DESK account isn't blocked from seeing a refund button — it's blocked from having that refund take effect without sign-off. Don't confuse an approval gate with a 403.
Where to review pending approvals
/admin/approvals lists everything waiting on a decision, oldest first, with the full context of what was proposed and by whom. Staff mobile has its own equivalent screen for on-the-go review.