Skip to content
IntelliAuth

Edit a user profile

User detail page → Profile tab. Every field is in-place editable: click, edit, save. Each save is one audit-log entry.

Editable fields

Section titled “Editable fields”
  • Email — primary email. Editing triggers email verification on the new address (configurable; you can also mark it verified directly).
  • Name — display name. Auto-splits into given_name + family_name on save.
  • Given name / Family name — independently editable.
  • Picture — URL of a profile picture. Usually populated by social federation (Google / GitHub).
  • Locale — IETF language tag (en-GB, en-IN, fr-FR). Used by IntelliAuth to localise emails it sends on your tenant's behalf.
  • Custom attributes — anything your tenant defines. See Custom attributes.

Immutable fields (greyed out):

  • User ID — the platform's internal identifier. Never editable.
  • Created at — the original create timestamp.
  • External identities — the linked Google / GitHub / SAML accounts. Manage on the Identities tab, not here.

Changing the primary email

Section titled “Changing the primary email”

Email changes are sensitive — they're how users prove identity, reach reset flows, get notifications. The platform's flow:

  1. You change the email on the Profile tab → Save.
  2. The platform sends a verification email to the new address.
  3. The user clicks the link to confirm.
  4. Until they confirm, the user's email stays the old one but a pending_email field carries the new one.
  5. After confirmation, email updates and pending_email clears.

If you want to skip the verification (e.g., you've verified the new email out-of-band), toggle Email verified in the same save. The change applies immediately; the user doesn't receive a verification email.

Why this matters: a malicious admin (or a stolen admin session) shouldn't be able to silently re-direct a user's email without verification. The verify-by-default flow blocks that.

Updating name / locale

Section titled “Updating name / locale”

No special handling. Save and it's in. Audit log records the change with before/after.

If your application reads name claims from the access token, the change takes effect on the user's NEXT sign-in (or next silent refresh). Tokens already in flight carry the old name until they expire.

Custom attributes

Section titled “Custom attributes”

Open the Custom attributes pane. Fields look like a key-value list. Add, edit, remove. The same fields are visible to your application via the access token (or via the management API) — see Custom attributes for the schema and naming conventions.

What you can't do

Section titled “What you can't do”
  • Edit historical email — once changed, the previous email is in audit but not re-editable as a separate field. If a user reverts, you change the email forward, not backward.
  • Edit external identities — the linked Google account's email, for example. That belongs to Google; IntelliAuth reflects what Google says. To "fix" the linked email, unlink + re-link.
  • Edit the user_id — never. Permanent identifier.

Common gotcha: customer asks "can you change my email to X?"

Section titled “Common gotcha: customer asks "can you change my email to X?"”

Procedure: verify the customer's identity first (a sensitive change), then change in the admin console. Toggle Email verified ON only if you've verified the new email belongs to them. Send them a confirmation message via the OLD email so they can flag if something's off.

The audit log captures every email change with you as the actor; this is the paper trail for the change.