Require a password reset when you create a user
Console-created users can be forced to set a password on first sign-in, and optionally receive an invite email at creation time.
From the changelog: User onboarding enforcement rules
Authdog Team

Provisioning a user from the console used to create a directory record and leave first-sign-in policy to the operator. That is easy to get wrong: a temporary password in chat, or an account that can sign in before the person has set their own secret.
Administrators can now set two flags when creating a user: changePw to require a password reset on first sign-in, and sendInvite to email the person immediately.
This is the longer note behind the August 30 changelog entry.
How it works
createUser on the management API accepts optional booleans changePw and sendInvite. The console Users create form passes both. The directory API exposes the same flags for programmatic provisioning.
When changePw is true, the user record stores that flag. Hosted sign-in treats it as a required password change before the session is fully usable. The flag is also visible on GraphQL user types and user analytics so you can see who still has onboarding outstanding.
When sendInvite is true, Authdog sends a create-user invite email after the record is written. Invite send is best-effort: a mail provider failure is logged and does not roll back user creation. The mutation message distinguishes "User created and invite sent" from a create-only success.
Audit metadata on USER_CREATED records both flags (sendInvite, changePw) so you can see how the account was provisioned.
Set it up
In the console, open Users, create a user, and enable:
- Require password change (
changePw) when the person must set their own password before using the app. - Send invite (
sendInvite) when they should get the email immediately.
You can set both. Invite without changePw still creates a usable account if you also set a password. changePw without invite is useful when you will share access out of band.
Directory clients send the same fields on user create.
Trust boundaries
changePw is an onboarding control, not MFA. It does not replace password policy, breached-password checks, or bot protection on the reset form. The invite email is not a proof of identity by itself; treat it as a delivery channel to the address you entered.
Failed invite send still leaves the user in the directory. Check the mutation message and mail logs before assuming the person received the link.
Try it
Create a test user with both flags, then sign in on the hosted Account Portal and confirm the password-change step. The original release note is in the changelog.