Provisioning a clientadmin
A clientadmin is a delegated compartment administrator: it creates, renames, merges and assigns compartments, and it reads no document at all. Only an administrator can provision one. What the account can do afterwards, and why it must be unable to read, is described for the person holding it on the compartments guide.
What a clientadmin is for
A delegated administrator: an account that shapes the compartment structure — create, rename, merge, and assign people — AND is in charge of all users on the system (user-directed 2026-09-11): it invites and creates accounts, resends and corrects invitations, disables and re-enables them, and reads the user list. It holds ZERO compartment grants, so it can read no document at all, and that is the point rather than a limitation: an account that could both merge compartments and read documents could merge any compartment into one it belonged to and read everything inside. TWO THINGS IT CANNOT DO. It cannot create an `admin` — refused by the engine on every path, because an account able to mint an administrator could mint itself one. And it cannot touch the admin console's SETTINGS (models, mail relay, retrieval dials, sign-in policy), nor register agents, read the audit view, work the quarantine queue or purge: a setting is not a user. Hand this kind to the person who runs the engagement's accounts and decides who may see what, and an ordinary account to the person who needs to read. ANY NUMBER of clientadmins may exist and a clientadmin may invite another, so the job can have a backup.
Create one from the portal (the normal path)
Sign in as an administrator — or as an existing clientadmin, since 2026-09-11 — open Invite in the portal's left menu, paste the person's email address, and tick 'Invite as clientadmin' BEFORE submitting. Nothing else about the invitation changes: same required email address, same vault-generated temporary password the administrator never sees, same forced password change at first sign-in. The checkbox defaults to off, so a scripted caller or an older page invites ordinary people and never accidentally mints a delegated administrator. The invite streams one result line per address as it goes.
Create one without the page (scripted)
POST /api/admin/users as an administrator with kind 'clientadmin'. The engine's vocabulary for kind is closed — human, admin and clientadmin are the only values the provisioning path accepts, and anything else is refused rather than stored. This path does NOT send mail: the account is created with the password you supplied and the forced-rotation flag set, and telling the person is your job. Prefer the invitation page unless you are scripting.
POST /api/admin/users # {"kind": "clientadmin", "identifier": ..., "email": ...}Or from the admin console
The console's Create user form has a Kind pulldown, and it offers clientadmin alongside human and admin. It had offered only the older two for as long as the clientadmin kind has existed — the route behind it always accepted clientadmin, so it was a short pulldown rather than a missing power, and it is no longer short. Like the scripted call, this path sends no mail: you supply the initial password and telling the person is your job.
What the account can then do
At first sign-in it must replace the temporary password like any invited account. Afterwards it lands in the portal, where Compartments and Profile are the surfaces it can use. Upload and Query open pages that say in words that the account holds no compartment, rather than offering forms that could only fail, and the document listing is absent for the same reason. Compartments is the workbench: the compartment table, create, rename and merge (with a warning naming both compartments before the click). Setting a person's access is no longer done here: one surface does grants now (ADR-0045), the Permissions view, where a cell is set to one of three levels — none, read, or write. Revoking is the none level, so a mis-assignment can still be undone by the account that made it.
What it can never do, and how that is held
It cannot give itself reach. The engine refuses a compartment grant whose target principal is of kind admin or clientadmin, per call — so a clientadmin driving a hand-built request at the grant route gets the same refusal the page would have warned about. That refusal is what makes delegating merge safe, and it is enforced in the database rather than only in the application, because a privilege-escalation path guarded in one file is guarded until somebody adds a second call site. Verify it on any deployment by trying it: the attempt is denied and audited.