Role Model
Last updated September 21, 2026
Map Matruno's current role names to practical administration, legal-process, matter, and audit responsibilities.
Current role families#
Use the role names the application already checks before inventing new labels:
| Role name | Where it appears | Practical meaning |
|---|---|---|
workspace_admin | Workspace membership, admin checks, settings/templates/integration writes | Workspace-level administration |
admin | Permission registry and admin helpers | Broad admin behavior inside a workspace |
platform_admin / system | User-level roles | Cross-workspace/platform admin paths |
process_manager | Permission registry and template write access | Legal workflow / process ownership |
operator | Permission registry | General legal-process operation |
member | Workspace member API | Baseline workspace membership |
auditor | Workspace member API | Review-oriented role name, with exact access depending on route checks |
case_manager / case_assistant | Human task filtering | Persisted matter/task participation role keys |
case_manager and case_assistant remain stored role keys in membership and task-filtering code. They describe matter participation, not a Cases section of the product.
Matter-level participant roles such as client, responsible_attorney, reviewer, and approver live on matter participants and are distinct from these workspace/process roles. See backend/app/core/legal_domain.py.
Avoid role sprawl#
Start from these names and document any deployment-specific mapping. Adding parallel names such as reviewer, supervisor, or approver at the workspace-role layer without code-level mapping can make audits and troubleshooting harder.
Review assignments when process changes#
Review role assignments when legal workflows change, connector scopes change, approval thresholds move, or a user changes teams. Access drift usually appears around operational change, not only code change.
Keep system admin separate#
Platform admin roles are user-level roles, not ordinary workspace membership roles. Do not grant cross-workspace behavior to workspace users unless the code path explicitly supports it. Confidential matter data must stay inside workspace and matter scope.
Was this helpful?