"Who can see salaries?" is the question that decides whether an HR system gets adopted. Here is the full answer, including how to verify it rather than take it on faith.
The five roles
| Role | Scope |
|---|---|
| Employee | Own records only |
| Approver | Own records, plus pending leave and claims for their people |
| Admin | Full company administration: employees, entitlements, reports, benefits, policies, settings |
| Super admin | Everything admin covers, plus onboarding, offboarding approval, management notes, entitlement overrides, audit log |
| Managing director | Company-wide read access and the audit log, without administrative controls |
Two things are restricted beyond plain admin. Management notes — performance material — are visible only to super admins and the managing director. Salary and NRIC are masked in the interface until an admin explicitly clicks to reveal, and NRIC decryption is audited every time.
Three enforcement layers
They are not redundant. Each catches something the others cannot.
- 1Request middleware. Unauthenticated requests are redirected to login. Admin routes reject non-admin roles before rendering. This is a coarse filter, cheap and early.
- 2Server-side action checks. Every mutation re-checks the caller's role inside the action. This is the layer that actually matters, because it is the one that still runs when someone crafts a request directly instead of clicking a button.
- 3Query scoping. Every query is filtered by the caller's company. A valid employee ID from another tenant returns *not found*, not *forbidden* — the isolation does not confirm that other tenants' records exist.
Revocation is immediate
Each employee carries a session version. Changing a role, terminating someone, or resetting a password increments it, and live sessions are re-validated against it. A demoted admin loses admin access now, not whenever their existing token expires. This matters most in the case you care about most: removing access from someone who has just left badly.
The audit log
Append-only, readable by super admins and the managing director, not editable through the application. It records who did what, to which record, when, with relevant metadata. Covered actions include NRIC decryption, entitlement overrides, role and status changes, deletion approvals, data exports, and any super-admin override of an approval decision.
Checking it yourself
The source is open, so you do not have to believe any of this. The three places to look:
src/proxy.ts— the request middleware and its route rules.src/lib/auth/helpers.ts— therequireAuthandrequireAdminguards every server action calls.- Any file under
src/lib/*/actions.ts— note that each query is scoped bycompanyId.
If you find a gap, the security policy in SECURITY.md explains how to report it.