Skip to main content
There are two ways someone joins an org: an explicit invitation to their email, or domain auto-join when their email domain matches one your org has allowed.

​
Inviting a member

Settings → Organization → Members → Invite member. Radar creates a one-time-use invitation and shows you a link to share. It doesn’t email invitations yet, so copy the link and send it yourself (Slack, your own email, and so on). The link is a bearer credential, so don’t post it anywhere public. The email match is enforced (the invitee can’t sign in as a different address than the one invited), and it expires after 7 days.

​
Pending invites

Pending invites show in Members → Pending. From there owners can:
  • Copy URL - get the acceptance link again to re-share.
  • Revoke - cancel before acceptance.

​
Removing a member

Owner-only. Members → Active → ⋯ → Remove. The user retains their account and any other org memberships - you’re only revoking this org’s membership. Their PATs scoped to this org are revoked immediately.

​
Changing a role

Owner-only. Members → Active → ⋯ → Change role. Changes apply on the user’s next request (no forced sign-out).

​
Domain auto-join

If your team all uses the same email domain, add it to Settings → Organization → Allowed domains to skip the invite flow entirely. New users who sign in with that email domain join automatically with the Default invite role you configured.
Free-mail providers (gmail.com, outlook.com, proton.me, etc.) are blocklisted - you can’t auto-join shared domains. Auto-join records a distinct org_member.auto_joined event in the audit log - separate from org_member.joined (accepted invitations) - so you can filter auto-joins from explicit invites by action.

​
Owners still need explicit promotion

Auto-joined users always get the default invite role (typically member). The system never promotes anyone to owner via auto-join - that always requires explicit role assignment.

​
Contact email for external users

A contractor who signs in as a guest through SSO is admitted under a synthetic address on a subdomain you own (for example dana@ext.example.com), not their real one. When your IdP sends a contactEmail claim, Radar keeps that real address and the Members list shows it on top, with the sign-in identifier beneath it. That real address is also what an invitation sent to their employer email matches against, so an invite and an SSO guest resolve to the same person. See SSO for external users for the setup.

​
Invitation flow under SSO

When the org has an SSO connection configured, invitations and domain auto-join still work - they’re additive. A user invited by email but who arrives via SSO will be matched on their verified email, and the invitation will resolve. For pure SSO orgs that want only SSO sign-ins (no email magic-link), restrict the IdP side to your domain - or set up domain auto-join with the IdP’s verified email and skip the invitation flow.

​
See also