The approval system

Some actions in Stay N Host are split into a request and a decision. The request parks a task; the decision - approve or reject - is what makes it real. The queue where those tasks wait is the Approvals screen, with a Pending tab (oldest first, the order you should work it in) and a Decided tab for the record.

One person can be both

Deciding requires the approval:decide permission and is always a human act - an automation or API token can never release a task. But since an owner decision of August 2026, the requester may decide their own request: the queue is a work list and a record, not a forced second-person gate. What keeps it honest is attribution - who raised a task and who released it are stamped independently, so a self-approval is plainly visible in the audit trail, never hidden. One more safety property: a task of a kind the system doesn’t recognize fails closed - it can always be rejected, but it can never be approved, because nothing registered knows how to release it.

Why the gate was relaxed

Small operations are often one person. A rule demanding a second approver that doesn’t exist blocks the work rather than controlling it - the queue used to strand requests nobody was allowed to release. The split (and its paper trail) stayed; the mandatory second person went.

Role routing - which job does the work

Separate from the queue, certain permissions are pinned to specific roles, so the kind of person doing each half differs even when no task parks:

Action	The role that holds it
Verify or reject a payment	Account Manager
Record a treasury transaction	Account Manager
Approve / execute a refund	Account Manager
Request a refund	Guest Manager
Cancel a booking, mark a no-show	Guest Manager
Revoke a guest’s ID verification	Booking Manager or Guest Manager
Resolve a damage claim	Conflict Resolution Manager
Generate a smart-lock code (integrated mode)	Airbnb Manager

These pins are also a hard ceiling for custom roles: a custom role you compose can never be granted any capability in this table, however senior the person. Moving money and releasing door codes stay with the named roles built for them.

The workspace policy - Settings → Approvals

What needs an approval at all is partly yours to decide, on the Approvals tab of Settings:

• Quotation links need approval - off by default. When required, releasing a quote link to a guest parks in the queue instead of going out immediately. The screen warns a one-seat workspace before it locks its own funnel.
• Guest cash needs a second approval - off by default. When on, a recorded guest cash payment parks for an explicit approval step before it posts. Any Account Manager may approve it, including whoever recorded it.

Both default off, and turning one on changes behavior only from that moment.

The floor that never moves

Whatever the policy says, one rule is not configurable: automation never decides an approval and never moves real money. Every approval decision, payment verification, refund, and payout requires a signed-in human. Agent rules can send messages and release door codes under their own gate - money is not expressible in a rule at all.