Not every user lives in the platform daily. An external reviewer signs off on a contract twice a quarter. A partner submits a compliance form three times a year. A customer approves a proposal, once, in a process they'll probably never repeat. For these users, the password is a tax — a small recurring frustration that has to be paid every time they want to do something they find only mildly important. They've forgotten the password since last time; they click reset; they wait for the email; they type something new; they promise themselves they'll remember it this time; they don't. Multiply that friction by every occasional user across every external workflow and the cumulative drag is significant. Magic-link login removes that tax in the cases where it's most painful.
The flow is two clicks. The user enters their email address on the sign-in page. The platform sends a one-time link to that address. The user clicks the link. They're signed in. No password to remember, no password to set, no password-complexity error to decode, no reset-request loop to navigate. Possession of the mailbox is the credential — which is exactly what a password reset implicitly relies on anyway, but without the intermediate step of pretending that passwords were adding security on top.
Links are time-limited. A link issued at 9 a.m. that's still valid the following week is a security hole, not a convenience; links expire on a short schedule — measured in minutes, not days — so a stale email in an inbox isn't a standing invitation to sign in. If the link has expired, the user requests a new one, and the process takes another fifteen seconds. That constraint is what keeps the "email as credential" model from leaking access over time.
Links are single-use. Once a link has been consumed to sign in, it's done. An attempt to reuse it later fails, which matters in case a link is forwarded, intercepted, or lingers in a mail history. A one-time link means one sign-in; anything beyond that is a fresh request and a fresh link. That simple rule closes the replay-attack window without any additional machinery.
Tenant awareness means the link lands the user where they're supposed to be. In a multi-tenant deployment, a user's email might be associated with one tenant or several; the link carries the tenant context and drops the user into the right one without asking them to pick. For external users who might not know or care which tenant they're accessing, that routing keeps the flow from feeling bureaucratic. They click a link, they're in.
Magic-link login coexists with password login. Users who prefer the familiar password flow can continue to use it; users who'd rather skip the password can choose the magic-link path. The platform doesn't force the choice — both options are available on the sign-in page, and the user picks what fits. For regular users who sign in daily, passwords (or better yet, single sign-on) remain appropriate; for occasional users, magic links remove the friction.
Magic-link login coexists with SSO. For tenants that use an identity provider for their main user population, magic links can still serve external users who don't belong to the provider's directory — a customer reviewing a proposal, a partner submitting a form, anyone who doesn't have a corporate account. Admins can restrict magic-link eligibility to non-SSO accounts, so internal users go through the provider and external users go through email — each audience routed through the flow that fits them.
Magic links for invitations close the loop between onboarding and first access. When a new user is invited to the platform, the invitation email itself can function as a magic link: clicking it signs the user in immediately rather than routing them through a password-setup round-trip before they can do anything. For inviting external collaborators or one-off users, that single-click onboarding is the difference between them showing up and them shrugging and giving up.
Rate limiting prevents the mechanism from being abused. Repeated requests for links to the same email address are throttled; attempts that look like enumeration or harassment are blocked; the normal case of a user requesting a link after mistyping the first one still works. The platform errs on the side of genuine user convenience while making the mechanism an unattractive target for abuse.
Audit of issuance and consumption is the compliance side. Every magic-link request, every link issued, every successful sign-in via a link, and every failed or expired attempt is logged. For tenants that need to demonstrate who accessed what and when, magic-link sessions are first-class citizens of the audit trail — no less traceable than password or SSO sign-ins.
When to offer magic links is ultimately a tenant decision. They shine for external collaboration portals, customer-approval flows, one-time-form submissions, and any other context where the audience is occasional and a password requirement would be unreasonable friction. For internal users who sign in daily, other flows are usually more appropriate. Admins configure the policy per tenant, and each tenant picks the shape that matches its audience.
The broader identity story is covered in the adjacent articles: authentication covers the password-based path, single sign-on covers the identity-provider-federated path, user invitations covers the onboarding flow that magic links can streamline, and the email engine article covers the delivery of the links themselves. Magic-link login is the right answer for a specific subset of users; offered alongside the other flows, it's what makes the platform accessible to the full range of people who might legitimately need to sign in.