Managing Users
The Users page is where you create and manage your application's end users β HCPs, Organizations, Patients, and Devices. Each is a data owner; creating one in Cockpit provisions both the data-owner entity and the User account that logs in as it. For the entity types themselves see HCP Β· Patient Β· Device and Organization.
Where the Users page livesβ
- Single-tenant project β the project's Users page.
- Multi-tenant project β each tenant has its own Users tab; a user belongs to one tenant.
See Managing Tenants.
Adding a userβ
Add offers the four user types β Healthcare professional, Organization, Patient, Device β each with its own form:
| Type | Identity | Contact | Parent organization |
|---|---|---|---|
| HCP | First name + Last name | Email, Mobile phone | optional |
| Organization | Name | Email, Mobile phone | optional |
| Patient | First name + Last name | Email, Mobile phone | required |
| Device | Name (+ Serial number) | optional |
A Patient can't be created without a parent organization β it's the party they share data through. See Organization.
To create many at once, use Import β see Bulk Import.
The Users tableβ
Each row shows the user's type, name, email, enrolment status, and account status. Search by name, email, or phone (min. 3 characters) and filter by user type. The β― menu on each row holds the actions; expanding a row reveals the details and the per-user collections you can manage.
Account status vs enrolment statusβ
- Account status β whether the user can sign in: Active, Registering, or Disabled. (A Critical issue tag overrides it if the user references a parent organization that no longer exists.)
- Enrolment status β whether the data owner's private key is initialized. Until it is, the user can't create or read encrypted data. See Recovery & Private Keys.
Overflow menu actionsβ
The β― menu on each row acts on the user as a whole:
- Edit β change the user's details, roles (Roles & Permissions), or parent organization.
- Initialize Private Key (HCP, if uninitialized) β set up the key for your own test/admin HCP only; real users initialize their own keys via your app. See Recovery & Private Keys.
- Activate / Disable β toggle whether the account can sign in (its Account status).
- Inspect β¦ JSON β view the raw entity.
- Delete β remove the user.
Expanded row actionsβ
Expanding a row shows the user's identifiers β the data owner's id (Healthcare party ID / Patient ID / Device ID), the User ID, the Parent ID, contact details, and assigned roles β and lets you manage three per-user collections:
Custom propertiesβ
Typed keyβvalue metadata attached to this user β the same model as a project's/tenant's Custom Properties, just scoped to the user. Add, edit, or delete an Identifier + Value with a declared Type (Boolean, Integer, Double, String, Date, Clob, Json). Use it to store your own data about the user that isn't part of the standard schema; your application reads it back from the entity.
Authentication tokensβ
Long-lived tokens for programmatic / API access as this user β distinct from interactive login. Generate authentication token takes a Token name and an Expiration date and time; the token's value is shown only once, so copy it immediately. You can delete tokens you no longer need. See Authentication.
Auto-delegationsβ
The set of other data owners this user automatically shares with whenever it creates new data. The most common case is the parent organization: with auto-delegation in place, data the user creates is shared with the parent, so others under the same parent (e.g. HCPs in the same clinic) can access and decrypt it. Registration authentication processes can set this up automatically for users they create; here you can see and adjust it per user. See Auto-delegation for the full picture.
Where to go nextβ
- HCP Β· Patient Β· Device and Organization β the entity types in depth.
- Bulk Import β create many users from a spreadsheet.
- Roles & Permissions β what each user can do.
- Recovery & Private Keys β initializing and safeguarding keys.
Cardinal SDK reference: Registering users β creating
Users and their data owners from the SDK.