Skip to content
Sertiq Sertiq Docs

Removing a user

Removing a user revokes their Sertiq sign-in. Their authored records (NCRs, CAPAs, comments) stay under their name for traceability — ISO auditors expect to see who did what, even after the person leaves.

This is an admin-only action, performed from /settings/users (Workspace access).

Before you remove

Section titled “Before you remove”

Run through this checklist. The UI does not force it, but skipping a step leaves orphaned work for whoever inherits the account.

  1. Reassign their open CAPAs. Open /capa, filter by assignee, and reassign each open or in-progress CAPA to another teammate. If you remove a user with assigned CAPAs, those CAPAs keep the old assignee_id and surface a User no longer in workspace badge on the row — they still need an owner.
  2. Close or reassign their open NCRs. Same idea: NCRs they raised stay under their name, but if they were the active investigator, hand the work over.
  3. Check @-mentions. Past mentions remain on the timeline, but new mentions will not deliver. See @-mentions in CAPA updates.
  4. Decide on the matching Employee record (if any). The two lists are independent — see Workspace access. Removing a workspace member does not delete the Employee record.

How to remove

Section titled “How to remove”
  1. Open /settings/users.
  2. Find the row for the user you’re removing.
  3. Click Remove.
  4. Confirm in the modal. The action is audit-logged with action = 'member_removed', the target user_id, and the acting admin’s user_id.

The user is signed out within seconds (next request fails RLS), their org_members row is hard-deleted, and any pending invitations they hold are cancelled.

What stays

Section titled “What stays”
RecordStays after removal?
NCRs they raisedYes — author email shown on detail page
CAPAs they assignedYes
CAPAs assigned to themYes — but flagged User no longer in workspace until reassigned
Comments / timeline entriesYes
Audit log entriesYes
Their Employee record (if any)Yes
Their attachmentsYes

What’s removed

Section titled “What’s removed”
  • Their org_members row — they lose all data access for this organisation.
  • Their active session — invalidated on next request.
  • Their pending invitations to this organisation.
  • Their @-mention deliverability — historical mentions stay on the timeline as text, but new ones won’t email them.

Constraints

Section titled “Constraints”
  • You cannot remove yourself. Ask another admin. This stops accidental self-lockout.
  • You cannot remove the last admin. The RPC checks count(admins) > 1 before deletion. Promote someone first, then retry.
  • Hard delete, not soft. Sertiq removes the membership row outright — there is no “deactivated” middle state for workspace users today.

If they had multiple organisations

Section titled “If they had multiple organisations”

Removing a user from organisation A leaves their accounts in organisations B, C, … untouched. Each org_members row is independent. A user with no org_members rows still has a auth.users row but lands on the onboarding flow on next sign-in.

Audit trail

Section titled “Audit trail”

Every removal writes a row to audit_log with:

action       = 'member_removed'
actor_id     = removing admin's user_id
target_id    = removed user's user_id
org_id       = current organisation
created_at   = now()
metadata     = { "email": "...", "role": "editor" }

This row is immutable and surfaces under Settings → Audit log for admins.

Section titled “Related”