Skip to main content

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:

TypeIdentityContactParent organization
HCPFirst name + Last nameEmail, Mobile phoneoptional
OrganizationNameEmail, Mobile phoneoptional
PatientFirst name + Last nameEmail, Mobile phonerequired
DeviceName (+ Serial number)Emailoptional
caution

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​

Cardinal SDK reference: Registering users β€” creating Users and their data owners from the SDK.