Manage users

Find the people who sign in to your applications, check the state of their account, and act on it: edit a profile, reset a password, sign them out, disable the account, or open a support session. All of it is under Users in your tenant's dashboard; the matching management API operations are listed at the end for reference. Viewing users needs the View users permission, changing them needs Manage users, and impersonating needs Impersonate users.

Find a user

Users lists 20 people at a time, newest first, and loads more as you scroll. Choose the Username, Name or Created header to sort by it, and again to reverse the order; Name sorts by the name the column shows (the display name, else the first and last name, else the username) in any case. Search matches the start of any word in a username, display name, or first or last name, the start of an email address, and the start of an email's domain, in any case: adm finds admin, admin@exa finds admin@example.com, and udibo, udibo.com or @udibo.com finds admin@udibo.com. A word starting with @ matches only the domain, so @udibo.com skips udibo.com@example.com. Every word you type has to match. Beside the search box are Status (Active, Disabled, Suspended) and Account type (People by default, or include the Service accounts behind machine applications; the Account type column appears once they are included). More filters holds Email verification, Created after and Created before, and says how many of them are applied. Choose Apply, then select a row to open that person's page.

Add a user

People usually arrive by signing up through your application, under the sign-up mode you chose. To add someone yourself, such as your first user:

1. Open Users → Create user.

2. Enter a Username. First name, Last name, Email address, Display name and Password are optional. A password must be at least 8 characters; leave it blank for someone who signs in with a social provider or an emailed code.

3. Choose Create user. You land on the new user's page.

A username must be one a person can sign in with. Sign-in reads anything with an @ as an email address and anything made only of digits, spaces and + - ( ) . with 7 or more digits as a phone number, and it ignores spaces around what is typed. So a username can't start or end with a space, contain @, or look like a phone number; Create user, Edit, sign-up and the Management API all refuse one and say which rule it breaks. Usernames stay case-sensitive.

The address starts unverified, and creating the account sends no email.

Read a user's page

The header shows the username, a Disabled, Suspended or Erasure scheduled badge, and the Edit and More buttons. The page then shows the account's details and email verification, whether it has a password (No password for an account created with a passkey or one whose owner removed it), two-factor enrollment, its passkeys, the reason a disabled account was disabled, its tenant-wide Roles (see Permissions), Linked identities, Active sessions each with Revoke, and the 20 most recent audit events under Activity. Metadata holds two JSON editors: Metadata (admin), which the person cannot edit, and User metadata, which they can. Save metadata replaces both; see Sign-up fields.

Edit changes the username, names, display name and email. Moving the email to a different address clears its verified mark.

Maintain an account

The More menu holds account maintenance. Reset password sets a random password, shows it to you once, and signs them out everywhere; pass it on through a channel you trust. Email a reset link sends a reset email. Mark email verified and Send a verification email appear while the address is unverified. Clear email suppression appears when mail to the address was stopped, for example after a bounce, and lets your tenant email it again.

Let people change their own email

People can change their own email address under Change email on the hosted /profile page. The change is on by default. Turn it off under Settings → General → Let users change their email address, then Save email change setting. While it is off, links already sent stop working too, and you can still change an address yourself with Edit.

A change goes through these steps:

1. The person confirms it's them:

   • with their password, if they have one;

   • otherwise with a code from their authenticator app or a recovery code;

   • otherwise with a code emailed to their current address.

   Anyone with a passkey for the site can use it instead, with a fingerprint, face or PIN, whichever of these they would otherwise use.

   An account with no password and no authenticator app can add an authenticator app or a passkey after signing in again with its social sign-in method instead of confirming with a passkey it already has. For 24 hours after one is added that way, no password, authenticator app or passkey on the account can confirm an email change, so someone who has taken over the social account cannot also move the email address. The page says when the change becomes available, and the account's verified address is told about the new authenticator app or passkey and the time. The code emailed to the current address still works during those 24 hours only while the account has no authenticator app: once one is on, the person cannot change their email address any way until the 24 hours are up.

2. Udibo emails a link to the new address. The account keeps its current address until the person opens that link, within 24 hours, while signed in to the account that asked for the change. Someone who opens it signed out, for example on another device, is asked to sign in and comes back to the same link to finish; someone signed in to a different account is asked to switch. Until then nothing changes and the link stays usable. This stops anyone from taking over an address by getting its owner to click a link for a change they never asked for.

3. If another account already uses the new address, that address gets a notice instead of a link. The page answers the same either way, so the form cannot reveal who has an account.

4. Once the change is made, Udibo emails the previous address, if it was verified, with a link that undoes the change for 7 days. The undo restores that address and signs the account out everywhere. Until the link is used or expires, the previous address stays reserved for that account: a sign-up, an import, your own Edit or another person's change cannot take it, and each is refused as if another account already used it.

Social sign-in methods stay connected through a change. The audit log records user.email_change.requested, user.email_change.completed and user.email_change.reverted.

Sign out, reset MFA, disable or suspend

The Danger zone at the bottom of the page:

• Revoke all sessions ends every session on its next request; they can sign in again at once. See Sessions and sign-out.

• Reset multi-factor, shown while they are enrolled, removes their authenticator and recovery codes and signs them out. See MFA.

• Disable this account takes a required reason, then Disable account signs them out everywhere, revokes every access and refresh token issued to them (including the tokens applications hold on their behalf and a service account's machine tokens), invalidates any password reset or verification link already sent, and refuses sign-in. Their username and email stay reserved. Enable account undoes it but brings back no session or token, except for an integration's service account (below), which stays suspended. You cannot disable your own account.

• Suspend user also refuses sign-in, ends their sessions, revokes every token issued to them as Disable account does, and releases the username and email for someone else. Every one-time link already sent for the account stops working, including password reset, email verification, account unlock, emailed sign-in and a pending email-change confirmation. The one exception is the undo link sent to their previous address after an email change: it keeps working, and that address stays reserved for them until the link is used or expires. The record is kept, and Unsuspend user restores it without bringing back any session or token. If someone else has reused the username or email, restoration is refused with a conflict. The conflicting identifier must be changed on its current account before you can restore the suspended one. Use Disable this account for a temporary pause that keeps the username and email reserved.

• Neither works on the only owner of an organization: the action is refused with a 409 naming the organization, so it is never left without an owner. Make another member an owner, or delete the organization, first. Until then you can still Revoke all sessions.

• A service account cannot be suspended or unsuspended on its own: the page does not offer either action, and the API refuses both with a 409. You can disable one. Disabling the service account of an integration bound to one of your resources retires that integration too, and the service account is then suspended with it: Enable account cannot bring either back.

Erase a person's data

Request erasure, in the Danger zone for anyone who can manage users, is separate from Suspend user. It opens a page that spells out the consequences and asks you to type the person's email address (or their username if they have none) before it will go ahead. The page works without JavaScript.

Requesting erasure:

• suspends the account now, signs the person out everywhere, and starts a 30-day quarantine;

• erases the account permanently once the quarantine ends: a daily job removes the profile, sign-in methods, sessions, tokens, consents, passkeys, memberships and role assignments. Audit events are kept for their normal retention period with their personal details scrubbed, and database backups keep a copy until they expire. An email-suppression entry (kept so the address is not mailed again), any copy already delivered to a CRM workspace (removed only by CRM erasure), and rate-limit counters that expire within a day are not removed;

• can be cancelled until then.

While an erasure is pending the page shows Erasure scheduled with the date, and Cancel erasure for anyone who can manage users; a reader sees the notice and no controls. Cancel erasure leaves the account suspended: use Unsuspend user afterwards to let them sign in again. Unsuspend user is not offered while the erasure is pending, and the API refuses it with a 409.

A request is refused, with the reason shown on the page, when the account is a service account, an application still acts as it, its Udibo billing account still has a live subscription or an unsettled invoice, it is the only owner of an organization or managed tenant (transfer ownership first), or its access to the tenant ranks at or above yours. It is also refused for a machine credential, and a tenant may make 50 erasure requests a day.

Open a support session

Support impersonation is off by default. Turn it on under Settings → General → Allow support impersonation, then Save impersonation setting. The owner, admin and support access levels carry Impersonate users.

1. Open the person's page, then More → Impersonate.

2. Read the list of what you cannot do, and enter a Reason of up to 500 characters. Reference a ticket where you can.

3. Choose Start impersonating. Your browser opens the session on your tenant's own host and lands on your first-party application, or on a status page if you have not registered one.

The session lasts at most one hour; end it early with Stop impersonating. You cannot impersonate yourself, a disabled or suspended account, a service account, or an administrator whose access level over the tenant is equal to or above yours. Udibo issues no tokens to an impersonated session and refuses every change, so you see your tenant's hosted account pages, read-only. The audit log records the start and end with your reason, and the person sees both on their own security page.

Management API reference

These operations are dashboard-only today; see choose the right API. Paths are under https://www.udibo.com/api/identity/{tenantId}:

The list takes search, status, emailVerified, type, createdAfter and createdBefore, parsed the same way as the dashboard filters; an unknown value is refused with a 400. It sorts with orderBy (id by default, createdAt, updatedAt, username or name) and orderDirection; repeat both with each page's cursor. disable and impersonate take {"reason": "..."}, and password takes {"password": "..."}, checked against your password policy. impersonate returns a single-use handoffUrl to open in the browser. The full reference is in the API reference.

Limits today

• There is no invitation email for a user you create, no bulk action, and no immediate deletion; Suspend user keeps the record, and Request erasure erases it after 30 days.

• The dashboard's Create user form checks only the 8-character minimum, not your tenant's password policy; the API checks the policy.

• Clear email suppression has no API equivalent.

• Roles assigned on a user's page are tenant-wide, unless you opened the page from an organization's Members section: then the page says so, and the roles you assign there apply only in that organization. See permissions and roles for how the three scopes work.

• No dashboard control lifts a sign-in lockout; see Protect accounts.

Next: protect accounts, read the audit log, or manage sessions.

Last verified 2026-11-11.