Users, roles & access¶
This is the administration of who can do what: user accounts, the roles that bundle permissions, the approval policy that governs four-eyes, and the audit trail.
Where: the Access & Security group.
The model¶
Recall the two-dimensional access model: a role is a bundle of functional permissions plus an approval tier plus a branch binding. A user is assigned one or more roles, and the two dimensions combine: a person might capture many actions but only authorise up to their tier.
Screens¶
| Screen | Purpose | Permission |
|---|---|---|
| Users | User accounts and their access | admin:users |
| Roles | Roles and the permissions they grant | admin:users to view, admin:role-manage to edit |
| Permissions | The permission catalogue | admin:users |
| Approval policy | Maker-checker thresholds and required approvers | admin:users to view, approval-policy:manage to edit |
| ACL templates | Record-level access templates | access:acl-read |
| Audit | Who changed what, when | admin:users |
Defining a role¶
Access & Security → Roles. A role carries a code (uppercase), a display name, a maker-checker tier, a branch-bound switch, and a grouped multi-select of permissions:
- Tier: None, T1 (checker, ≤ 1M), T2 (senior checker, ≤ 10M) or T3 (manager, unlimited).
- Branch-bound: on for roles that should see only their branch (teller, branch manager); off for head-office roles.
- Permissions: grouped by domain (
account:*,payment:*,journal:*, …), each with a description.
Editing roles needs admin:role-manage.
The seeded roles¶
Cortex ships with a set of standard roles you can use as-is or adapt. A selection:
| Role | Tier | Branch-bound |
|---|---|---|
| Teller | None | Yes |
| Chief Teller | T1 | Yes |
| CSR | None | Yes |
| Operations Officer | None | Yes |
| Payments Officer | None | Yes |
| Payments Supervisor | T2 | No (HQ) |
| Loan Officer | None | Yes |
| Credit Approver | T2 / T3 | No (HQ) |
| Compliance Officer | None | No (HQ) |
| Finance Officer | None | No (HQ) |
| Financial Controller | T3 | No (HQ) |
| Branch Manager | T2 | Yes |
| Product Manager | None | No (HQ) |
| System Administrator | None | No (HQ) |
| Auditor | None | No (HQ), read-only everywhere |
| General Manager | T3 | No (HQ) |
Approval policy¶
Access & Security → Approval policy is the authorisation matrix behind
Approvals. Each rule maps an operation and an amount band to the number of
approvers required and their minimum tier. Zero approvers means straight-through. Changes take
effect immediately. Editing needs approval-policy:manage.
Audit¶
Access & Security → Audit records changes to users, roles and reference data: who, what and when. The Digital Identity group's audit view covers logins and credential changes. The Auditor role has read-only access across the platform for exactly this kind of oversight.
How permissions reach the app¶
Your identity provider issues a token carrying your permissions and your role tier (and, where branch scoping is enabled, your branch). The backend maps permissions to authorities and enforces them on every operation; the approvals system keeps the tier check. So the same access rules apply whether you act through the console or the API.
Roles that do this work¶
| Task | Permission | Typical role |
|---|---|---|
| Manage users | admin:users |
System Administrator |
| Manage roles | admin:role-manage |
System Administrator |
| Set approval policy | approval-policy:manage |
System Administrator, General Manager |
| Oversight across all approvals | approval:view-all |
General Manager, Auditor |