Appearance
Users & Roles
Where to find it: Administration, then Users & Roles (/admin/users).
System role templates
OrviQ seeds ten role templates. They are starting points — you can clone and adapt them, or build custom roles from scratch.
| Role | Purpose |
|---|---|
| Tenant Administrator | Full tenant administration. A locked anti-lockout role |
| Compliance Manager | Owns the compliance lifecycle |
| Compliance Officer | Works obligations and validation |
| Risk Manager | Owns the risk register |
| Risk Officer | Maintains risks |
| Control Owner | Maintains controls and submits assessments |
| Assessor | Runs control assessments |
| Reviewer | Reviews and approves submissions |
| Auditor | Reads everything, plus the audit trail |
| Read Only | View-only access |
The Tenant Administrator role is locked
It exists to prevent a tenant locking itself out of its own administration. It cannot be archived or stripped of administration rights.
It still does not confer the never-auto-granted permissions below.
Permissions that administration does not grant
Four permissions are excluded from every system role template, including the Tenant Administrator's grant:
| Permission | Why |
|---|---|
tprm.assess | Governed third-party risk assessment is a professional judgement |
tprm.classify | Regulatory classification is a professional judgement |
tprm.decide | Approving a material outsourcing arrangement is a governance decision |
assessment.review_self_override | The segregation-of-duties break-glass |
To grant any of them, assign it deliberately to a custom role. Administrator status alone never satisfies them.
Permission scopes
Permissions can be scoped, narrowing what a holder can act on.
| Scope | Means |
|---|---|
any | Across the tenant |
own_unit | Within the holder's organisational unit |
own | Only records the holder owns |
Scopes union on a widest-wins basis: any includes own_unit, which includes own. A user holding a permission at two scopes through two roles gets the wider one.
Scope is how you make a role reusable across a group
A "Control Owner" role scoped to own_unit can be assigned to every business unit's control owners without each seeing the others' controls. One role definition, many assignments.
Custom roles
Roles can be created from a template, by cloning an existing role, or from blank.
| Action | Permission |
|---|---|
| View roles and permissions | roles.read |
| Create custom roles | roles.create |
| Edit role names and permissions | roles.update |
| Archive custom roles | roles.archive |
| Grant and revoke roles to users | roles.assign |
Only permissions present in the canonical catalogue can be granted. A grant naming a permission outside the catalogue is dropped, which prevents stale or invented permission strings accumulating in role definitions.
Users
| Action | Permission |
|---|---|
| View users | users.read |
| Create user accounts | users.create |
| Edit user profile and department | users.update |
| Deactivate and reactivate accounts | users.deactivate |
| Issue temporary passwords | users.reset_password |
| Assign functional owners to requirements and activities | users.assign_owner |
Organisational units
Units are the departments and business units that structure your tenant. They drive:
- Permission scoping at
own_unit - The
owner_department_headworkflow resolver, which routes a department review stage to the owner's head of department - Department filtering in reporting, based on the governed owner's unit
| Action | Permission |
|---|---|
| View units | org_units.read |
| Create, edit and archive units | org_units.manage |
A missing unit assignment breaks two things quietly
A user with no organisational unit cannot be reached by the owner_department_head resolver, and is absent from department filtering in reporting.
Neither produces an error. The workflow stage routes nowhere and the report row is simply missing. Check unit coverage when either symptom appears.
Roles and workflow stages
Workflow stages bind to role keys — strings your administrator controls. The workflow engine has no notion of what a role means; it routes to whoever holds the bound key.
Two consequences worth planning for:
Renaming a role changes who receives a stage without any template change.
One person holding two consecutive stage roles collapses a chain. A six-eye chain where the same individual holds both the Compliance Officer and Compliance Manager roles is a four-eye chain in practice. The engine blocks the same person acting twice, but it cannot know that two roles are held by one individual.
Review role assignments against your chain configuration periodically. This is the most common way a well-designed chain silently loses depth.
Designing a role set
Start from the templates. They encode a workable Three Lines separation.
Separate maker and checker roles deliberately. If your Compliance Manager holds both mapping.propose and mapping.review, per-record segregation still blocks self-approval — but the role no longer expresses the separation.
Scope rather than duplicate. One own_unit-scoped role beats eight unit-specific roles.
Keep the never-auto-granted permissions in narrow roles. tprm.decide in a role held by two people is meaningful; in a role held by twenty it is not.
Review on joiner, mover and leaver. Movers are the risk: someone who moves from operations to compliance and keeps both role sets can approve their own prior work.
Example
A bank's role set.
| Role | Based on | Holders | Notable |
|---|---|---|---|
| Tenant Administrator | System | 2 | Platform configuration only |
| Head of Compliance | Compliance Manager, plus tprm.classify | 1 | Approves applicability and policy |
| Compliance Analyst | Compliance Officer | 6 | Proposes; approves nothing |
| Head of Third-Party Risk | Custom | 1 | Holds tprm.decide |
| Risk Manager | System | 2 | Risk review stages |
| Chief Risk Officer | Custom | 1 | Holds risk.accept and exception.approve |
| Control Owner | Control Owner, scoped own_unit | 84 | Sees only their unit's controls |
| Internal Auditor | Auditor, plus audit.* | 4 | Read everything, plus finding validation |
| Read Only | System | 31 | Business stakeholders |
What the design achieves: tprm.decide sits with one person, risk.accept with one, and the 84 control owners each see only their own unit. Six analysts can propose across the estate and approve nothing.
Troubleshooting
"An administrator cannot approve something." Four permissions are never auto-granted. Assign them deliberately.
"A workflow stage routes to nobody." Its role key names a role no user holds, or the owner_department_head resolver cannot find a unit.
"A user sees fewer records than expected." Their permission is scoped to own_unit or own.
"A permission I granted has no effect." It may not be in the canonical catalogue, in which case it is dropped. It may also require an entitlement that is off.