Work & Platform
Roles & Audit
Permissions are set as a matrix rather than inherited from a role name, and every sensitive action is written to an audit log that cannot be edited from the app.
How it is used
Role permissions per module, and an audit log of who changed what. The audit trail records the action regardless of which module it came from.
How it works, screen by screen
Every screen below is the real one, photographed from a working tenant, with the route it lives at so you can go straight to it.
- 01
Grant by role, not by person
/admin/rolesPermissions per module, per role. Somebody promoted inherits the role's access instead of a hand-built set of grants nobody can audit afterwards.
- 02
Every sensitive action is logged
/admin/auditActor, target and timestamp, recorded whichever module the change was made in — so the question is what happened, not who remembers it.
What it does
- Role permission matrix across every module
- Per-permission grants rather than blunt role tiers
- Audit log of sensitive actions with actor and timestamp
- Server-side enforcement, not just a hidden menu
- Filterable audit history for compliance reviews
- Company owner retains override
Where to find it
Administrators
- /admin/roles
- /admin/audit
How it connects to the rest
Nothing below is an integration to switch on. These are the same records, read and written by more than one module.
Comes from
Feeds into
Looking for what this replaces and why it matters? See the Roles & Audit overview.