Case governance
Case Management separates investigation duties so a role can be limited to the work it performs. The system administrator receives the installed case permissions by default. Custom roles must be updated explicitly.
| Permission | Access |
|---|---|
cases:read | View the case list and case detail |
cases:create | Create a case |
cases:manage | Edit investigation details, add notes and tasks, link evidence, and make non-final transitions |
cases:evidence:read | View and link bounded evidence snapshots, subject to source access |
cases:restricted:read | View, create, and edit cases classified RESTRICTED, and view restricted-case fields in lists and exports |
cases:assign | Change the case's owning team or assignee |
cases:decide | Resolve, close, or reopen a case through an allowed transition |
cases:export | Export an approved case package when export is available in the installed release |
case_settings:read | View case types, dispositions, and related settings |
case_settings:manage | Change institution-managed case settings when editing is available in the installed release |
Assign cases:read with operational case permissions so users can navigate to and inspect the records they manage.
Assign cases:evidence:read only where source evidence is part of the user's approved duties.
Teams
Case ownership uses Teams rather than case-specific queues. teams:read permits viewing teams and their membership
under Settings → Teams; teams:manage permits creating, editing, deactivating, and reactivating teams and
managing membership. These are separate from the case permissions above — team membership never grants case access
by itself. See Case workflow for how team ownership and assignment work.
Confidentiality
Cases support two classifications: STANDARD and RESTRICTED. Unlike the other classifications in this table,
RESTRICTED is enforced, not just a handling signal: a user without cases:restricted:read cannot see a restricted
case in the list or detail view, and cannot create or edit a case as RESTRICTED. The client must define which
roles receive cases:restricted:read, how exports of restricted cases are approved, and how disclosure is
prevented.
Audit and retention
Case notes, evidence snapshots, assignments, and timeline events are append-only at the database boundary. Case mutations lock the current record and create a timeline event in the same transaction. This prevents an investigation change from succeeding without its case history.
The client remains responsible for retention periods, legal holds, backups, database access, and disclosure policy. Deleting a user or source record must not be used to erase a retained case history.