Invite flow
A pending place in a workspace that becomes a real membership when the invited person verifies who they are and accepts.
What it is
An invite flow represents a future membership before the person has an account. An admin chooses an email and role, the system creates a pending invitation with an expiring single-use token, and acceptance turns it into a workspace membership. Slack's familiar email invite is the canonical product shape.
Reach for it as soon as one user can bring another into shared data. Pending, accepted, expired, and revoked are real states, not email copy. Existing users should accept into their current account, while new users can create credentials and return to the same invitation.
The gotcha is treating possession of a forwarded link as proof of the invited email. Require a login with that verified address or an admin approved reassignment. Consume the token and create the membership in one transaction so double-clicks cannot make duplicates, and decide what a resend does to older links.
Ask AI for it
Add a workspace invite flow backed by PostgreSQL. Create an invitations table with organization_id, normalized_email, role, invited_by, token_hash, status, expires_at, accepted_at, and timestamps. Generate a 32-byte token with a CSPRNG, email the raw value once, and store only its SHA-256 hash. On acceptance, require a signed-in user with the same verified email, lock the invitation with SELECT FOR UPDATE, reject expired or revoked records, create the membership with a unique (organization_id, user_id) constraint, and mark the invitation accepted in the same transaction. Add resend, revoke, and pending-list actions, invalidate older tokens on resend, and prevent invitations from granting the owner role.