Skip to main content

Users and access

/users lists the laboratory's people. /users/new invites one, /users/:userId shows a membership and /users/:userId/edit changes it.

The page is available to a laboratory owner or laboratory manager. It is not on the navigation for anyone else, because offering a door that answers "forbidden" is worse than not offering it.

The membership is the record

A person's access to a laboratory is their membership row, and it carries the role, the release scope, who granted it, and when they were last active.

It is never deleted. Access is withdrawn — the row stays, so every result that person entered still names a record that exists. Restoring returns both the role and the release scope.

The address uses a printable reference (u-1001). No name, email or employee number ever travels in a LabFlow URL.

The ten roles

Role
TechnicianAt the bench. Enters and checks results all shift
Senior technicianChecks other people's work and owns the rule set
PathologistSigns out cases. Reads the patient, not the worklist
PhlebotomistAway from the bench most of the day. Collection and custody only
ReceptionistThe front desk. Registers people and takes payment
Laboratory managerThe only persona whose home really is a dashboard
Quality officerAudits the laboratory. Reads everything, enters nothing
Billing clerkNever touches a specimen. Money and stock only
Laboratory ownerOwns the tenant and the public listing. A marketplace persona
Platform adminAcross every tenant. The only persona that is not laboratory staff

Four of them may release a result: senior technician, pathologist, laboratory manager and quality officer.

Release scope

Beside the role sits the release scope — which of the laboratory's departments this person may release within. It uses the same nine-department vocabulary as the setup wizard and the public listing.

An empty scope means enters only.

Who may grant what

Bounded, and enforced on the server rather than only offered by the screen:

  • platform_admin is never granted here.
  • lab_owner only by a laboratory owner.
  • Under the "any verified user" invitation policy, a person who is neither owner nor manager may grant only the laboratory's default invitation role.

The same rules run in the browser (to offer) and in the server function (to refuse).

Invitations

An invitation resolves or creates the account and sends the email. An invitation whose email fails to send is removed, so no partial invitation is left behind.

It is accepted by signing in with that address and choosing the laboratory. There is no second confirmation screen — signing in proved the address.

The membership trail

Every change is appended to a trail nothing can edit: invited · accepted · signed_in · role_changed · scope_changed · scope_cleared · access_withdrawn · access_restored.

It is written by a database trigger, so every writer is recorded — not only the ones that went through this page. No client role can insert, update or delete a row in it.

Identity events are not copied here; they are read from the identity verification record, which owns that fact.