Skip to main content

Users, roles & permissions

What it does​

Administrators control who can sign in and what each person is allowed to do. Access is built from user types (categories of staff/accounts), roles (bundles of permissions), permissions, policies, and scopes that limit a person to certain organizations or facilities. You can only grant scopes and roles at or below what your own account holds (delegation rules).

Where to find it​

Administrators work under Admin → Access:

  • Users — /admin/access/users
  • Roles — /admin/access/roles
  • User type ↔ roles — /admin/access/user-type-roles
  • User roles (assign roles to accounts) — /admin/access/user-roles
  • Permissions — /admin/access/permissions
  • Policies — /admin/access/policies

User types themselves are maintained under Setup → User types (/admin/setup/user-types), including the Care provider flag used by staff registration and portal routing.

📸 Screenshot: the Users admin list (access-users).

Access users

📸 Screenshot: user type ↔ roles (access-user-type-roles).

User type roles

Common tasks​

Add a user and give them access​

  1. In Users, select New, enter the person's details (and user type when offered), and Save.
  2. Assign one or more roles appropriate for that user type.
  3. Prefer roles that are already linked to the user type under User type ↔ roles so the picker stays consistent.

Categorize roles by user type​

  1. Open User type ↔ roles.
  2. Select a user type and attach the roles that accounts of that type may receive.
  3. Staff/provider registration and the user Roles tab then offer only sensible roles for that type.

Set what a role can do​

Open Roles, choose a role, and adjust the permissions it includes. Everyone with that role is affected. You cannot grant permissions you do not hold yourself (except platform super_admin).

Limit a user with scopes​

Open a user → scopes (/admin/access/users/[userId]/scopes) — or a provider’s scopes — and grant geographic / facility scopes at or below your own. For division scopes, pick the division through the hierarchy (country → … → division), not an empty flat list.

During staff registration, a registrar with broader scope can place the new account’s workspace scope appropriately (instead of always locking it to the registrar’s current facility).

Add a contextual rule​

Use Policies for rules that depend on context beyond a simple role.

Tips & limitations​

  • Prefer roles over one-off permissions — easier to manage and audit.
  • Access is enforced server-side and at the record level; also see Visibility & consent.
  • You cannot edit your own roles, a role you currently hold, or the role set of your own user type (anti-privilege-escalation).
  • Platform Global / GLOBAL scope is reserved for operators; ordinary facility admins will not see it as a grantable option unless they are allowed to delegate it.

Clinical staff see every patient registered at the facility they are signed in to, unless that patient is marked as confidential (VIP). Nurses, doctors and other clinicians do not need any admin permission for this, and they do not need to have treated the patient before.

The same rule covers recording as well as viewing: staff who hold a write permission can record against a non-VIP patient at their facility without anyone granting them that patient first. What you may do is still decided by your permissions; the patient is simply no longer a separate barrier.

Two things decide it:

  • The facility on your session. Patient search shows the facility you are currently signed in to, not everywhere in your organisation. If you work across several hospitals, switch facility from Select facility and search again.
  • Whether the patient is confidential. A patient marked confidential is hidden from ordinary facility search, deliberately. They appear only for staff who have been granted access to that specific patient, or through the emergency break-glass route, which is recorded.

If a patient you expect is missing​

  1. Check the facility name at the top of the screen. A patient registered elsewhere will not appear.
  2. Ask whether the patient is marked confidential. If so, someone with the right permission has to grant you access to that patient, and the grant is logged against your name.
  3. Only then treat it as a fault, and note that a search which returns nothing looks the same whether the patient does not exist or is hidden from you. That is intentional: showing the difference would itself reveal that the person has a record here.

When something looks wrong​

What you seeWhat it usually is
A permission you want is not in the listNo module has declared it — an undeclared permission cannot be granted at all
A role grants a permission but the user still cannot actTheir scope excludes the record, or the module is disabled
A user type change does not alter what they seeUser type and roles are different layers — roles carry the permissions

For the causes common to every screen — a missing menu item, an empty list, a refusal — see Why a screen will not work.