A user can't sign in and wants their password reset. Or you suspect their password has leaked and want to invalidate it. Or you're onboarding someone and need to set a starter password. Three paths, three situations.
Path 1 — Send a reset email (user picks new password)
Section titled “Path 1 — Send a reset email (user picks new password)”User detail page → Actions menu → Send password reset email.
The platform sends the user an email with a one-time link. They click, set a new password, sign in. The link is valid for 24 hours (configurable per tenant).
This is the default for "user forgot their password" requests. The user picks the new password themselves; you don't see it; the platform records "password reset email sent" + "password reset completed" in audit.
Path 2 — Set a temporary password directly
Section titled “Path 2 — Set a temporary password directly”User detail page → Actions menu → Set temporary password.
You type a password. Two toggles:
- Password must be reset on next sign-in — defaults to ON. Forces the user to change it the next time they sign in.
- Notify the user via email — sends a "your administrator set a temporary password" email. Defaults to ON.
Use this when the user can't receive email (corporate IT issue, their inbox is locked) or you need them onboarded right now. Communicate the temporary password via a secure channel (password manager, in-person, phone call — not email if email is the problem you're working around).
Path 3 — Force reset on next sign-in (no new password set)
Section titled “Path 3 — Force reset on next sign-in (no new password set)”User detail page → Actions menu → Force password reset.
The user's existing password stays valid for sign-in, but on the NEXT successful sign-in the platform immediately demands a new password before letting them into the application. The new password must satisfy the tenant's password policy.
Use this when:
- The password policy changed and you want existing users to re-pick under the new rules.
- You suspect the password has been observed (shoulder-surfed, etc.) but want to keep the session active.
- A scheduled rotation is due.
What happens to sessions
Section titled “What happens to sessions”Resetting a password (paths 1 and 2) does NOT auto-revoke existing sessions. The user stays signed in on their current devices; they only need the new password for future sign-ins.
If you want to revoke too (e.g., the password was compromised and you suspect the current session is also compromised), do both: reset the password AND revoke sessions from the user's Sessions tab.
Every action above lands in audit:
user.password_reset_email_sentuser.password_set_by_admin(withtemporary: trueflag)user.force_password_reset_setuser.password_reset_completed(when the user actually completes the reset)
Useful for "who reset this user's password" investigations.
Federation note
Section titled “Federation note”If the user signs in via SSO (Google, SAML, etc.) and has no password identity, the reset paths above are not applicable — there's nothing to reset. The Actions menu greys them out.
To force a federated user to re-authenticate, revoke their sessions instead.