#Profile Settings
#Overview
Client Admin, Client Manager, Client Staff, Partner Admin, and Partner User can all edit their own supported profile fields: first name, last name, mobile number, timezone, and portal language. Portal role is a read-only access assignment. Selecting a partner client never selects another person's profile or credentials.
Customer roles use Account > Profile and Account > Security (/account?section=security). Partner Admin and Partner User sessions edit their own profile at bare Settings > Profile (/settings). Internal administrators and operators use Profile (/profile) for personal security. The partner organisation/IP-allowlist Security panel is a separate feature.
Email address remains read-only in the profile form; a verified email-change flow handles email updates. The profile mobile field is separate from the native SMS recipient.
#Your sign-in methods
The same personal controls appear in the three existing security homes. Each credential's availability comes from current native ownership, policy and actual confirmation. An email domain, saved SSO configuration, a summary badge or an enrolled-method label cannot authorize a change. A linked account keeps its supported local credentials. Employer-managed or unverified credentials show their reason and the support route independently of other methods.
| Method | Available workflow |
|---|---|
| Password | Confirm your own native password and required method; deliberately enter current/new/confirm values within five minutes. Native effective policy decides acceptance. |
| Authenticator app | Read current native status, confirm, start and verify six digits. Setup is available alongside other supported factors; a READY authenticator is never overwritten. |
| Remove current authenticator | One confirmation popup removes your authenticator. This browser stays signed in and your other sessions are signed out. No sign-in is required before or after removal. |
| Replace authenticator | Preserve and test another usable strong method, remove the current authenticator under native safety rules, then obtain the setup form's separate fresh confirmation to set up the new app. No automatic deletion or replacement. |
| Passkeys and security keys | Read the complete own native READY-key list and remove the exact selected key under current strong proof and native usable-alternative rules. |
| Register a passkey | Confirm strongly, then complete the existing secure sign-in domain's code-bound ceremony in the same tab. The original Portal remains the configuration/result home. Existing keys and origin remain intact. |
| Linked sign-in provider | Read the complete own native linked list. Unlink only the exact held handle with proven usable local sign-in and current native permission. |
| Email one-time code | Only Client Admin and Partner Admin have the separate enable/disable controls when native verified-email, policy and proof allow them. Enabling sends no setup code; receiving/checking a login code is a separate normal sign-in. |
| SMS | Configuration is unavailable until acceptance of the SMS workflow. Contact support. An existing enrolled SMS method remains usable through permitted normal sign-in. |
| Recovery | Use another enrolled method or an already-issued recovery code if normal sign-in offers it, then identity-verified administrator/AiDial support. Issuance/regeneration is unavailable here. |
No normal customer configuration control opens the provider console. Operator recovery tooling is separately restricted.
#Authenticator setup and resume
Choose Confirm it is you, then Start authenticator setup. Add the full selectable manual key to your app and deliberately submit its six-digit code. No seed or code is stored by the Portal or included in logs. Expiry, cancellation or leaving clears local entry without deleting a native method. If you already saved the pending key, choose I already added the pending key; this option is also available when native inventory reports no READY authenticator because that list cannot prove absence of a pending seed. A deliberate restart has a separate confirmation and can invalidate the old pending key.
A known successful verification ends earlier logins, including the performer. Sign in normally again before current-state readback and protected access. An enrollment or recovery acknowledgment does not complete a fresh MFA challenge. A deterministic wrong-code refusal permits a bounded deliberate next code. An uncertain write stays blocked even after a pending/empty list, expiry or another login; use the named verified support path rather than starting, verifying, or deleting another method.
#Passkey continuation
Native setup uses the existing auth domain in this tab. Returning to the Portal or a changed key list is not completion. The server must match the exact operation/code to the own READY key after a newer validated same-subject normal login, then return to the original security home with its result.
If you leave an unexpired ceremony, Resume this exact registration redirects to that existing native capability without issuing another one. Stop this registration here stops local navigation, retains exact reconciliation custody, and does not remove a key. Expired/cancelled/unknown operations require exact reconciliation and fresh ordinary authentication or identity-verified support. Never remove an old key because a new registration timed out.
#Verified email changes
- Enter the new address, choose Confirm and request email change, and complete strong own native confirmation. Re-enter the same address after returning. Authority is bound to that recipient and expires after 300 seconds; email/SMS alone cannot redirect their recipient.
- Acknowledged native
SetMyEmailrecords a pending contact and uses the provider's existing verification delivery. Earlier Portal sessions end. Continue secure sign-in and verification opens normal hosted authentication in this tab; it must verify the current pending address before final OIDC login can complete. The Portal accepts no verification code and has no partial-login exception. - After verification and a fresh ordinary login, the pending request remains visible as a masked Keep this verified email or Restore original email choice. A status read never silently activates it. Explicit keep synchronizes the own local account/assignment projection after authoritative matching readback.
- Restoration requires verifying the pending mailbox and completing fresh strong ordinary authentication first. It sets the retained original address, requires a NEW code at the original mailbox, then another fresh login and explicit restoration readback. It is not instant cancellation or an immediately verified rollback.
- If local synchronization fails after verification, use Retry email sync for that exact request. It sends no new Set or code. Unknown provider outcomes stay blocked and visible; never resend automatically. Expired proof, an expired/lost continuation or an inaccessible mailbox uses identity-verified support at
help@aidial.com.au.
Old-email MFA delivery/check can remain available while a contact change is pending. It does not verify the current address or constitute a full login. The established login name is not changed by a Portal username workflow.
#Changes and results
Save work first. Removing your authenticator keeps this browser signed in and signs out your other sessions. If the status can't be checked afterwards, refresh instead of removing again. Other material native credential commits end earlier native logins, including the performer, and require fresh normal sign-in before readback. Local audit or session-cleanup failure is reported separately and cannot turn a known commit into a safe retry. Recovery acknowledgments record only the current non-secret marker and do not issue codes or alter native credentials.
Buttons have accessible labels, keyboard operation, deliberate destructive confirmation and focus/error notices. Pending controls prevent overlapping submissions. Contact status remains masked. English, Japanese and Korean resources are present; actual deployed locale acceptance is separate.
#Common issues
| Issue | Next step |
|---|---|
| Required MFA is incomplete | Use the existing role-specific remediation home, complete normal native MFA, and sign in again. A badge does not release the restriction. |
| Removal refused | Keep existing methods, read current status and deliberately confirm only when a usable permitted alternative exists. |
| Setup timed out or outcome unknown | Reconcile the exact held operation or use identity-verified support; do not blindly retry or delete another method. |
| Pending email cannot be cancelled yet | Verify the current pending mailbox and obtain fresh strong normal authentication before restoration, or use verified support if that mailbox is unavailable. |
| Contact change completed but session refresh failed | Reload the page or sign in again. The contact change is complete; do not repeat it. Any audit or session-cleanup warning still applies. |
| SMS configuration requested | Contact support; existing SMS sign-in and configuration acceptance are separate. |
| Lost all usable methods | Contact your organisation administrator or help@aidial.com.au. Do not send codes, seeds, tokens or challenge screenshots. |
#Scope and security
Browser writes use the existing CSRF/same-origin protected routes; server handlers repeat own live session, assignment, role and MFA checks and inject server-only bearer/ID proof. Queries/body identity selectors, delegated account writes, admin-token fallbacks and saved SSO/domain ownership inference are refused. Responses use no-store and closed error/DTO projections.
#Related guides
The Portal cannot bypass MFA and does not store raw recovery codes.