An owner can't be locked out of their own account

If an account's recorded owner ends up marked pending, the app recognises them as approved by definition and repairs their record rather than parking them on a waiting screen.

What it is

Two coordinated rescues. Middleware checks, for any user headed to the waiting screen, whether they are the recorded owner of an active account — and if so lets them past and injects their account. The bootstrap endpoint then repairs their stored identity to admin/approved so the fast path holds on every later request without a database lookup.

Also called: owner locked out · stuck on pending approval · can't log in after migration

See it
An owner can't be locked out of their own account
Area
Platform & Admin
Group
Sign-in
System
Multi-Tenancy & Identity
Solves
3 named problems
01The middleware rescue runs only for users already headed for the approval screen, so the ordinary path pays nothing.
02It looks up an active account whose recorded owner is this user, cached per user for sixty seconds.
03On a match the pending redirect is skipped and the account is injected into the request headers.
The waiting-for-approval screen crossed out, with the dashboard behind it — the rescue path skipping the gate. src/middleware.ts. Sample data — no customer information appears here.
How it works
  1. 1The middleware rescue runs only for users already headed for the approval screen, so the ordinary path pays nothing.
  2. 2It looks up an active account whose recorded owner is this user, cached per user for sixty seconds.
  3. 3On a match the pending redirect is skipped and the account is injected into the request headers.
  4. 4The bootstrap endpoint performs the durable repair: account, admin role and approved status written onto the identity.
  5. 5Self-escalation is impossible because the recorded owner field is only ever set by the owner-gated assign-owner flow or by provisioning.
Why we built it

The middleware comment names the exact scenario: the signup webhook stamps 'pending' on every non-platform-owner at creation, which is 'correct for self-serve /join strangers', but 'a legitimately provisioned TENANT OWNER whose Clerk user gets (re)created — a Clerk instance cutover, or their first sign-in via a new OAuth identity — also lands on pending, and has no invitation to self-heal against, so they're stranded on /pending-approval with no way back in.' The comment then names the real case it was written for: this is exactly how the owner of the first account got locked out after an auth-provider cutover. The safety argument is stated in the same block: the owner field 'is only ever set by the platform-owner-gated assign-owner flow or by provisioning, never by the user, so this can't be self-escalated.'

The problem
  • An account's owner had nobody above them to approve their own access.
  • An identity-provider migration reset owners to pending with no path back in.
  • Repeated database lookups for a state that should be repaired once.
Sound familiar?
What you get
The owner of an account is never locked out of it.
The fix is durable — it repairs the stored record, not just the current request.
The rescue costs nothing for normal sign-ins.

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 →