Support isn't put in your approval queue

A vendor support or sales rep opening a customer's account is never sent to that customer's approval queue — the queue is for the customer's own staff.

What it is

A middleware rescue that checks, for a user already headed to the waiting screen, whether they are active platform staff — and if so, lets them through. The server auth layer makes the matching decision: staff cleared to enter accounts act as admin/approved inside the account so they can actually help.

Also called: support stuck on waiting for approval · vendor staff access · help desk can't get in

See it
Support isn't put in your approval queue
CustomerBuildingAmountStatus
Sutter KlineEquipment Storage$15,450Open
Gideon Alt40×64 Shop$5,950Draft
Sutter KlineBarndominium$15,640Approved
Gideon AltBarndominium$16,400Sent
Gideon AltRiding Arena$14,880Draft
The support rep's view of a customer account with full navigation, next to the approval queue that correctly contains only the customer's own pending users. src/middleware.ts and src/lib/serverAuth.ts. Sample data — no customer information appears here.
How it works
  1. 1Runs only for users otherwise headed to the approval screen, cached per user for sixty seconds.
  2. 2Matches on the staff record's linked identity id, which is stamped on first successful resolve — so only someone who has already accepted their invitation and signed in matches.
  3. 3The server auth layer independently grants staff-with-impersonation admin role and approved status inside the account.
  4. 4The role a staff member gets inside an account is derived from their platform role rather than granted flat.
Why we built it

The comment states the situation and calls it out as absurd on its face, dated Keith 08-10: stamping pending 'is correct for a stranger self-serving through /join. It is wrong for our own staff: an invited Support or Sales rep opening a customer's subdomain to help them was redirected to Waiting for approval INSIDE that customer's account — asking the customer to approve our employee.' The matching note in the bootstrap endpoint describes the second half of the same bug: middleware let staff through 'and then found no org, no membership and the least privileged role. That is the session needs a refresh banner, with the sidebar labelling a platform admin Worker.' The fix is capability-driven so 'adding a role in platform_staff is enough, and nothing here needs editing again.'

The problem
  • Vendor staff were treated as strangers signing up to a customer's account.
  • Customers were asked to approve the vendor's own employees.
  • Staff who got past the door still landed with no account, no membership and the lowest role.
Sound familiar?
What you get
Support can open your account and actually see it, without asking you to approve them.
Your approval queue only contains your own people.
Staff authority inside an account follows their platform role automatically.

See it on your own jobs

Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.

or keep browsing features →