Invite user

Problem Context

• A user with sufficient permission is adding another person to a workspace, organization, project, channel, repository, team, tenant, or shared resource.
• The invite may grant member, guest, admin, viewer, editor, channel, team, repository, enterprise, or external collaborator access.
• Invitations may be sent by email, username, directory lookup, invite link, group sync, or admin request.
• The invited person may need to accept, verify email, create or use an account, choose the correct identity, or wait for admin approval.
• Pending invites may expire, be resent, edited, canceled, extended, duplicated, bounced, accepted, or declined.

Selection Rules

• Choose invite user when the primary action is sending an invitation that grants another person future access after delivery or acceptance.
• Use account creation when the current user is establishing their own credentials or persistent access.
• Use object picker when the user is choosing an existing person or group record without sending a new invitation lifecycle.
• Use permission recovery when the current user is blocked and needs to request access for themselves.
• Use bulk import when admins are creating or updating many user records from structured data rather than sending a small number of trackable invitations.
• Use profile setup when the invited or existing user is completing their visible identity after access exists.
• Require explicit review for elevated roles, external collaborators, billable seats, guests, invite links, broad channels, or organization-wide access.
• Show pending, accepted, expired, failed, approval-needed, duplicate, and canceled states as invitation states rather than generic success or error messages.
• Let authorized inviters edit role or scope, resend or extend, and cancel pending invitations before acceptance where the platform supports it.

Required States

• Recipient entry or directory lookup state
• Role and access scope selection state
• Guest, billing, external, or elevated-access warning state
• Optional invite message state
• Review before send state
• Sent and pending state
• Admin approval requested state
• Duplicate or already invited state
• Expired or bounced invitation state
• Resend, extend, edit, or cancel pending invitation state
• Accepted invitation state

Interaction Contract

• Recipient entry identifies who will receive the invitation and clears or flags unresolved recipients before send.
• The invitation cannot be sent until required role, scope, and policy constraints are resolved.
• The review state summarizes recipient, destination, role, scope, message, expiry, billing or guest implications, and approval requirement.
• Sending creates a trackable invitation record with pending status rather than implying membership is active immediately.
• Duplicate invite attempts reuse, update, or surface the pending invitation instead of silently sending multiple conflicting invitations.
• Resend, extend, edit, cancel, approve, and deny actions update the pending invitation record and preserve audit-relevant context.
• Accepted or expired invitations stop showing unsafe send controls and route to membership, retry, or cleanup actions.

Implementation Checklist

• Define invite target type, recipient identifiers, accepted account matching, role model, scope model, guest limits, billing impact, expiry, approval rules, and audit requirements.
• Validate email, username, domain, duplicate pending invite, existing membership, role eligibility, guest plan support, channel or team constraints, and external sharing policy before send.
• Show role and scope preview before sending, especially for admin, owner, guest, external collaborator, organization-wide, or billable access.
• Implement pending invitation list, accepted state, expired state, resend, extend, edit role or team, cancel, approval request, denial, and notification return paths.
• Do not leak restricted workspace, project, or repository details in invite emails or pending records beyond what the recipient is allowed to know.
• Log inviter, recipient, target, role, scope, source, delivery method, timestamp, expiry, updates, cancelation, and acceptance.
• Test wrong email, unverified email, already member, duplicate pending invite, expired invite, admin approval required, external guest, high-risk role, failed delivery, mobile, keyboard, screen readers, and localization.

Common Generated-UI Mistakes

• Treating invitation sent as if the user is already a member.
• Hiding role, scope, guest, billing, external, or admin implications until after send.
• Sending duplicate invites instead of showing pending status.
• Letting users invite people to roles they cannot grant.
• Using invite links for broad access without expiry, deactivation, or scope explanation.
• Mixing invite user with account creation, profile setup, onboarding, billing, and role administration in one undifferentiated flow.
• Making cancellation, resend, and expiry impossible to find.
• Leaking restricted object names in invitation emails or approval messages.

Critique Questions

• Who will receive the invitation, and how is that identity verified or disambiguated?
• What role, team, channel, repository, workspace, or organization scope will they get?
• Does the invite create billing, guest, external sharing, admin, or data exposure consequences?
• Is approval required, and can the requester track the approval outcome?
• Where can admins find pending, expired, accepted, duplicate, and canceled invitations?
• Can pending invitations be resent, extended, edited, or canceled before acceptance?