Nobody gets in until you approve them

The identity-provider webhook stamps every new non-owner account as pending worker at creation. Middleware redirects a pending user to a waiting page and returns 403 on API calls. An admin approves from the team surface, which sets status, role and crew, mirrors the membership, and writes an audit entry. Approval is guarded so an admin of one company can't approve a user belonging to another.

Also called: pending approval · approve new user · waiting for approval screen · account approval

1. 1The signup webhook verifies its signature, then writes status pending and role worker onto the new identity.
2. 2The platform owner is exempt and stamped approved admin.
3. 3Middleware redirects any explicitly non-approved user to the waiting page, with a small allowlist of routes that must remain reachable.
4. 4The waiting page is forced light-themed because it is customer-facing and renders on a tenant's own address.
5. 5Approve sets status, role and crew, mirrors the row into the membership table, and audits the action with the approving admin's identity.
6. 6Cross-account approval is refused: the target's account must match the caller's, unless the caller is the platform owner.

• ◆Self-serve signups reaching a company's data before anyone vetted them.
• ◆An admin of one company being able to approve and promote a user in another.
• ◆New users landing on a broken-looking waiting screen as their first impression.