Platform users is the one list of every account on a DALP Instance, whichever organisation a person belongs to. Use it to find an account by name or email, to read what an account can do, and to act on one when a person cannot sign in or when access must stop. It is a platform administrator's screen: an organisation owner does not reach it, and nothing here changes an organisation's own membership or roles.
Each account has one page. That page carries the platform role, the account state, the organisations the person belongs to, the sessions that are open, the API keys the person holds, and the actions that change the account. An account closure request a person filed appears on the same page, and the administrator decides it there.
The “Platform users” page under “Platform admin”, with the account count beside the title.
The “Search by name or email” field and the filters “Platform role”, “Sign-in”, “Email” and “Onboarding” head the table, with “Export”. The columns are “Name” with the email address under it, “Platform role”, “Sign-in”, “Email”, “Onboarding” and “Created”.
Steps
Find the account
Open “Platform admin”, then Platform users. The title shows how many accounts match. The table has the columns “Name”, with the email address under the name, “Platform role”, “Sign-in”, “Email”, which says whether the address is verified, “Onboarding” and “Created”. Sort by name or creation date, and filter by platform role, sign-in state, email verification or onboarding status. The table also exports the rows that match as a file.
Search matches a name or an email address that contains what you type. Your own row is marked You.
The Sign-in column reads “Active”, “Banned” or “Closed”. A ban whose end date has passed reads “Active” again. The account page gives the detail: “Banned until” a date, “Banned until an administrator unbans them”, or “Closed on” a date.
Read the onboarding column
The Onboarding column shows one state per person, the worst across the organisations they belong to: “Stuck”, “In progress”, “Done”, or “No organisation” when they belong to none. For a person in several organisations whose state is “Stuck” or “In progress”, the cell also counts how many share that state, such as “Stuck · 1 of 3”.
An organisation is “Done” once its onboarding finished, and “Stuck” when its initial deployment failed three or more times. Anything else is “In progress”. Archived organisations do not count.
To read each organisation separately, expand the person's row in the list. It shows each organisation with its onboarding state and the person's role there. The Organisations section on the person's page adds the number of failed deployment attempts when a deployment failed. For a closed account, that section keeps the person's role in each organisation, such as “Owner”, and offers neither “Reset onboarding” nor “Archive organisation”. The page header and the “Sign-in” row carry “Closed”.
Open the account
Select the name. The page shows the person's name, or the email address when no name is stored, with the account state beside it. The Account card holds the email address, whether it is verified, the creation date and the user ID, which you can copy.
Change the platform role
The “Access” section shows the platform role: “Administrator” or “Member”. Select Change. A closed account shows its role with no “Change”.
Making a member an administrator asks you to type their email address, and says that administrators run every organisation on the platform. Changing your own role to “Member” warns that you lose Platform admin as soon as you confirm, and the Console then leaves the “Platform admin” section.
For an account that signs in with single sign-on, the identity provider decides the role at every sign-in: the account is an administrator while the provider sends the administrator claim, and a member otherwise. A change made here lasts only until that person's next sign-in.
When you are the only platform administrator, Change on your own row is unavailable, with the reason “You are the only platform administrator, so your role cannot change. Make someone else an administrator first.” The API still accepts that change. If it leaves the platform with no administrator, no later account becomes one by signing up: an operator with deploy access to the cluster restores the role through the migration Job, as Security and compliance posture shows. With single sign-on, the identity provider's administrator claim grants the role at the next sign-in.
Ban or unban the account
Select Ban user. The confirmation asks for an optional reason and for when the ban ends: “When an administrator unbans them”, or “On a date”. A date must be tomorrow or later, and the ban ends at the end of that day.
The confirmation states what the ban does: the person's sessions end now, they cannot sign in while the ban applies, and their API keys stop working until the ban ends. A ban turns no key off: once you lift it, or a ban with an end date runs out, the same keys work again.
Unban user replaces the action while a ban applies. Unbanning lets the person sign in again. The sessions the ban ended do not come back.
You cannot ban your own account. A closed account cannot be banned or unbanned: both actions answer 409 Conflict with ACCOUNT_CLOSED, and the Sign-in row reads “Closed on” a date with “A closed account stays closed.” in place of the ban action.
End a session
The Sessions section lists each open session with its device, its organisation, when it started and when it expires, and marks a session an administrator started as “Impersonated”. On your own page, the session you are using reads “Current session”. The device reads as on the person's Security page: the browser, or the start of the client's name for another client, such as DALP SDK v3..
End session signs one device out. “End all sessions” signs out every session at once. Neither touches the account's API keys, and neither can restore a session later.
On your own page the current session has no end control, and End all sessions is hidden.
Revoke a person's API keys
The API keys section lists the keys the person holds, newest first, in every organisation: its name with the start of the key, its organisation, when it was created, when it was last used and when it expires. A key the person turned off reads “Disabled”, and a key past its expiry reads “Expired”. A key with no organisation, or with an unknown scope, shows a dash under Organisation. Only a key created before the platform checked a key's organisation and scope can be one, as Authenticate with API keys explains. The list never shows a key's secret.
Revoke all API keys deletes every key the person holds after you confirm. A revoked key stops working within 30 seconds and cannot be turned back on, so any program that used it needs a new key. Use it when a person leaves, or with a ban, which only refuses the keys while it applies. Revoking does not stop the person: while they can sign in, they can create new keys. Ban the account first to stop that.
The section offers no way to revoke one key. The person revokes a single key on their own API keys page.
Act as the member
Impersonate opens the Console as that person, for one hour. Everything you do is real and runs as them, and the session records that you started it. That includes transactions from the person's wallet, which the platform submits as theirs and marks with your name as the impersonator.
The action is offered for a member account only. It is hidden on your own page, unavailable with “The account is closed” for a closed account, and unavailable with “Unban them first” while a ban applies.
While the hour lasts, a banner on every signed-in screen reads “Viewing the Console as” the person and the time the session ends, with Stop impersonating. Stopping ends the impersonated session, restores your own session and opens the person's page. Once the hour has passed the banner offers “Sign in” instead.
Some actions refuse an impersonated session, such as approving or rejecting anything that waits for a second person, switching an approval family off, changing the person's language, approving a device sign-in, adding a passkey or connecting an MCP client. Sign in as yourself for those. On the trading venue screens, Approve and Reject are disabled and read Sign in as yourself to decide. Maker-checker lists every decision the refusal covers. What the platform records lists the evidence an impersonation leaves.
Set a password
In the “Access” section, select Set password. A closed account has no “Password” row, so the action is not offered. The sheet states the password policy in force: by default at least 12 characters and three character types. The password changes without the old password and without an email to the person, so this is the way to restore access for someone who cannot sign in.
The sheet also offers to end the person's sessions in the same step. Setting the password turns off every API key they hold, before the new password is stored, so a request that presents one of those keys stops authenticating within 30 seconds of the change. If the keys cannot be turned off, the password does not change and the sheet reports the failure. If the password changes and ending the sessions fails, the sheet says so and points you at the Sessions section.
Decide a request to close an account
A person asks to close their account from Security. While a request is open, the account page shows a banner, “asked to close the account”, with the date and whether it came from the Console or the Investor portal, and the page header carries Waiting for you.
The banner keeps the steps the person sees inline: empty the wallets, hand over organisation ownership, and replace the checker. Each step names who acts: the person, or an organisation owner for the checker step. When an on-chain identity is bound to the account, the banner says to close the account rather than delete it.
Three decisions are on offer:
-
Delete user opens the delete sheet and stays unavailable, with the reason in words, while a step is open or an on-chain identity is bound.
-
Close account ends every session of the person, keeps the account record, stops their API keys, emails them, and settles the request as closed. Closing is permanent: the account then refuses sign-in with
403 ForbiddenandACCOUNT_CLOSED, whatever the sign-in method, and the Console and Investor portal show that message on the sign-in screen.While the person is still the only owner of an organisation, Close account is disabled with that reason and “Decline” leads. A close sent anyway answers
409 ConflictwithPLATFORM_, naming the organisations, and nothing is closed.ACCOUNT_ CLOSURE_ SOLE_ OWNER -
Decline asks for a reason of up to 500 characters, which the person receives by email. The account stays open and they can ask again.
Deciding a request that is no longer open answers 409 Conflict with PLATFORM_. When the person withdraws the request, the banner goes away. “Delete user” and “Close account” read the request again before they open. If the person withdrew or changed it since the page loaded, nothing opens. A notice then names the person and reads “withdrew or changed the request. Read it again before you decide.” Decline shows the same notice when you send the reason, and its sheet closes.
On your own page the banner shows the request without decisions, because another administrator settles it. Read a request through GET /api/, which answers 404 Not Found when the person never filed one.
Delete the account
Delete user sits in the danger area at the bottom of the page. It is hidden on your own page, and while a closure request is open, because the banner carries the decision. The row shows what the delete removes: the account, its sign-in methods and its sessions. It reads the reasons the platform refuses a delete before you act, and keeps the button unavailable while one applies:
Read the same reasons through GET /api/, which lists the organisations a sole-owner or checker reason names.
The sheet asks you to type the person's email address. It states that their KYC records, participant names and audit entries stay, and points at banning as the way to stop access and keep the record. Deleting is permanent for the account, and it also settles an open closure request as deleted and emails the person.
Find the account from an organisation
When you start from an organisation, open “Organisation participants”, then “Users”, then the person. The “Overview” tab shows a Platform account card with the platform role, the sign-in state, and “Open in Platform users”. Only a platform administrator sees the card. It has no action of its own, so every change happens on the person's Platform users page.
Create or update an account through the API
Platform users has no create or edit form. Both operations belong to the authentication administration API and need a signed-in platform administrator session: an API key is refused with 403 Forbidden.
POST /api/ creates a sign-in account from an email address and a name. The password is optional, and without one the account has no password to sign in with. The platform sets the role itself, whatever the request asks for: the account becomes a member. Only the first account on a new instance becomes an administrator. Creation adds no organisation membership, participant or wallet, so the person joins an organisation through an invitation.
POST /api/ changes stored account fields. It writes the name, the email address, the email-verified flag, the language, the platform role and the ban fields. Any other field, such as a phone number, is refused with 400 Bad Request and FIELD_NOT_ALLOWED, naming the field, and nothing is written. A password goes through Set password instead. For a closed account, a change to the ban fields answers 409 Conflict with ACCOUNT_CLOSED, while its other fields still change.
What the platform records
A platform administrator can lock a person out, by a ban, by ending their sessions, by revoking their API keys or by closing the account. An administrator can act as a member through impersonation, or take over the account by changing its email address and setting a password. A session started with that password is not marked Impersonated, so only the platform-wide entries for the update and the password set tie it to the administrator. The platform keeps this evidence:
- The impersonated session stores the administrator who started it, and the person's Sessions section marks it “Impersonated” while it exists. Stopping the impersonation ends that session. While you act as the person, their Security page shows it as the current session. The person's own Security page lists it too, in the Console and the Investor portal, with the line “Opened by <your name>, a platform administrator”. The person can revoke it, which ends your impersonation. The person gets no new-device email for it.
- Every change made in an impersonated session, and every sensitive read made in it, is an entry on the Audit trail of the organisation it was made in. The Operator column names the administrator and reads “Acting as” the person.
- A decision on a closure request stores the administrator who made it, which
GET /api/returns.v2/ admin/ users/ {user Id}/ account- closure- request - The account holds only its current ban: whether it is banned, the reason and the end date. An unban clears all three, and the Audit trail entries for the ban and the unban keep the earlier values.
Each administration action also writes one Audit trail entry: a ban, an unban, a role change, a password set, ending one or all sessions, revoking every API key, creating, updating or deleting an account, and starting or stopping an impersonation. The entry names the administrator, their platform role and the account, and holds the old and new values the action changed, such as the role or the ban reason. A revoke records how many API keys it deleted, never a key. A password set records only that the password was replaced, never the password, and no entry holds a session token.
An action the route refuses, such as one without the permission it needs, is recorded as failed with its refusal code and no values. A refusal made before the route runs records nothing: ACCOUNT_CLOSED on a closed account, FIELD_NOT_ALLOWED on an update, INVALID_ROLE_TYPE or YOU_ on a role, and a delete the deletion rules refuse, such as for an organisation's sole owner.
These entries belong to no organisation, so an organisation's Audit trail page does not list them. A platform administrator reads them through the platform-wide query of the audit trail.
Troubleshooting
The screen says Not available
Your account does not hold the Administrator platform role. Ask a platform administrator to grant it on your account page. Organisation ownership does not grant it.
My own page says I cannot ban my own account
Your own Sign-in row reads “You cannot ban your own account.” in place of the ban action, and the platform refuses
a self-ban with 400 Bad Request and YOU_CANNOT_BAN_YOURSELF. Ask another administrator to act.
Change is unavailable on my own page
You are the only platform administrator. Make someone else an administrator first. Banned administrators count towards the total, so Change becomes available as soon as another administrator account exists.
Delete user stays unavailable
Read the row that holds the button. It names the reason, and each reason has its own way out: another organisation owner, moving tokens, replacing a wallet checker, or, when an on-chain identity is bound, banning the account or closing it on the person's request.
Impersonate is unavailable
The button says which rule applies. Unban them first means a ban is in force. “The account is closed” means the account was closed on a closure request. The action is also absent for an administrator account.
The ban ended but the person is still signed out
A ban ends access for new sessions and ends the sessions open when it started. Nothing restores them, so the person signs in again.
The person says they are still signed in after I ended their sessions
Ending a session stops that session from working at its next request. An API key is not a session, and ending sessions never revokes one. Revoke all API keys in the “API keys” section stops every key the person holds, as Revoke a person's API keys describes. Setting their password also turns their keys off.
Frequently asked questions
Does a ban turn off API keys?
No, but it stops them. A ban ends interactive sessions, refuses new ones and refuses the person's API keys while it applies. The keys stop within 30 seconds. The keys stay turned on, so they work again once the ban is lifted or runs out. Revoke all API keys or closing the account stops them for good. API keys lists what stops a key.
What does deleting an account remove?
The account, its sign-in methods and its sessions. It leaves the person's KYC records, participant names and audit entries, so the record of what they did survives. The sheet states this before you confirm, and points at banning when the goal is to stop access and keep everything else.
Can an account be created on this screen?
No. Create and update accounts through the authentication administration API, as Create or update an account through the API describes.
Is an impersonation or a ban recorded?
Yes. A ban, a role change and the start and end of an impersonation each write an Audit trail entry that names the administrator, and an impersonation also leaves the administrator's name on every Audit trail entry made in that session. What the platform records lists every trace.
Does a closed account come back?
No. Closing ends sign-in and every session, and a closed account refuses a new session whatever the sign-in method. Its API keys are not revoked, but they stop authenticating within 30 seconds and stay refused. Banning, unbanning and changing its ban fields all answer 409 Conflict with ACCOUNT_CLOSED, and the person cannot file another closure request.
API routes
The screen reads and changes accounts through these routes of the Platform API:
GET /api/lists the accounts the table shows.v2/ admin/ users GET /api/reads one account and answersv2/ admin/ users/ {user Id} 404 Not Foundwhen no account has that identifier.GET /api/lists the reasons a delete is refused.v2/ admin/ users/ {user Id}/ deletion- refusals GET /api/reads an open closure request.v2/ admin/ users/ {user Id}/ account- closure- request