Skip to main content

Invitations

Invitations add users to an organization and, when applicable, a tenant, without requiring them to already have an account. The product supports org-wide and tenant-scoped invitation lists and a shared Invite user experience.

Creating an invitation​

Invite user (when you have permission) opens a form where you can configure:

  • Target — Organization or a specific tenant (from tenant context). The copy in the dialog reflects whether the invite is for the whole org or a tenant.
  • Email address — Every invitation is bound to the recipient's email and is delivered to that inbox. The recipient must sign in or register using that exact email to accept. Shareable generic links were removed; an admin who needs to invite multiple people sends multiple email-specific invitations.
  • Role — One of the roles returned by the available roles API (for example owner, admin, member, viewer), with a short description for each in the chooser.
  • Expiry — How long the invitation remains valid, for example from 1 hour up to 30 days; 7 days is a common default.

After submission, the system creates a record you can see in the Invitations tab, with list filters as provided by the UI (for example by status or search).

Org vs tenant invitation lists​

  • Identity Management → Invitations — Org-level list of pending and historical invitations for the current organization (with search).
  • Tenant settings → Invitations — The same Invitation list component, scoped to the current tenant when you opened tenant settings from Tenants.

Invite actions from org-level Users or Invitations use org scope. Invites from tenant Users or Invitations pass a tenant id so membership is tenant–scoped in the same way.

Accepting an invitation (invitees)​

The accept flow is served on a public route of the form /invitation/:token.

  • The page loads invitation details and branches based on state: valid, expired, or already used.
  • If the user is not signed in, they can sign in (including password and SSO where configured) or, when allowed, register to create an account and join.
  • If the user is already signed in as a different person than the invite’s email, the product warns before accepting, to avoid accidentally linking the wrong identity.
  • Google OAuth and similar options appear when your deployment supports them for registration or login.
  • On success, the user gains membership under the org (and tenant) specified by the invite.

Verification and account recovery use separate routes (for example /verification and /recovery/…); they are not the same as invitation acceptance but may be part of a new user’s first sign-in.

Revoking and lifecycle​

The Invitations list supports revoking pending invites. Because every invitation is bound to a specific email, sharing the link with the wrong person still won't let them join — only the addressed account can accept. Use short expiry for sensitive orgs and revoke any invitation that's no longer needed.

Removed: generic shareable links. Any pre-existing generic invitation rows were deleted by the email-only migration; only email-specific invitations exist going forward.