Staff access starts when they sign in, and stops when revoked

An invited staff member is activated the moment they sign in with the verified address they were invited at — and a revoked one can never re-grant themselves by signing in again.

What it is

Invitation acceptance handled at resolution time rather than through a callback URL, so it works however the person arrives — invite link, bookmark, or an account they already had. The address must be verified. Revoked rows are deliberately never rescued by that path. Every transition is appended to a staff employment record.

Also called: invite staff · revoke access · former employee access · offboard staff

See it
Staff access starts when they sign in, and stops when revoked
Area
Platform & Admin
Group
Vendor access
System
Multi-Tenancy & Identity
Solves
3 named problems
01Staff are matched by any email on their account, so someone invited at a work address who later changes their primary address keeps access.
02An 'invited' row plus a verified matching address flips to active, records the acceptance time and links the identity id.
03If the acceptance can't be persisted, access is refused for that request rather than granted on state that didn't save.
The team screen's staff rows with status chips (invited / active / revoked) and an employment-history log underneath. src/app/platform/settings/team/page.tsx. Sample data — no customer information appears here.
How it works
  1. 1Staff are matched by any email on their account, so someone invited at a work address who later changes their primary address keeps access.
  2. 2An 'invited' row plus a verified matching address flips to active, records the acceptance time and links the identity id.
  3. 3If the acceptance can't be persisted, access is refused for that request rather than granted on state that didn't save.
  4. 4The linked identity id becomes the durable key for someone whose addresses have all changed since.
  5. 5Only 'active' grants anything; 'revoked' is never rescued.
  6. 6Cached access can be dropped explicitly after a role change or revocation so it lands on the next request.
Why we built it

Acceptance was moved into the resolver deliberately: 'Doing it here rather than in a callback URL means it works no matter how they arrived — invite link, bookmark, or an existing Clerk account they already had.' The verification requirement is stated as a principle: 'an unverified address is a claim, and an invitation is addressed to a person, not to whoever can type their address into a signup form.' The revoked carve-out is the sentence that matters most: 'a former employee signing in again must not re-grant themselves by existing.' And the persistence check is the kind of detail that only comes from having seen the alternative — grant on unsaved state and 'they'd hold it only until the next request.'

The problem
  • Callback-based acceptance breaks for anyone who arrives by a different route.
  • An unverified address could claim someone else's invitation.
  • A revoked employee re-granting themselves simply by signing in again.
Sound familiar?
What you get
Access begins on first sign-in with no extra step.
Revocation is final, regardless of how someone signs in afterwards.
Role changes take effect within seconds, not on the next cache expiry.

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 →