Reference
Who can see what
Mālama holds records that can affect somebody's livelihood, so access is narrow on purpose. This page explains what your role gives you, and why a colleague may see something you cannot.
The five roles
An account can hold more than one. Roles are fixed — they are written into the application alongside the permissions they carry, so nobody can create a new one by name and have it mean anything.
HR Administrator
Everything: all incidents including restricted ones, all reviews, the directory, positions, job titles, departments, user accounts, import, retention settings and legal holds. Give this role to as few people as the work allows.
HR Staff
Day-to-day HR work. Standard incidents, all reviews, the full directory, employment history, and filling or vacating positions. Restricted incidents are invisible unless granted one individually. Cannot manage users or settings.
Manager
Can report incidents and see only those they reported or were assigned to handle. Writes and shares reviews for their direct reports. Sees the directory and their reports' employment history.
Employee
The directory, their own profile, and their own reviews once shared — which they can acknowledge and respond to. No access to incidents at all, including ones about themselves.
Auditor
Reads the audit trail: who did what, to which record, and when — without the contents of those records. Designed so compliance can be checked without widening access to the files themselves.
Incidents: the rule is not the org chart
This is the part that surprises people, so it is worth stating plainly. Incident access is decided by confidentiality level, explicit grants, and role. It is never "incidents about the people who report to me".
Why managers do not see incidents about their reports
Because the complaint may be about that manager. A rule that followed the reporting line would hand the accused the file on the accusation — and everyone in the organisation would learn that, which is how a reporting system stops being used. Managers see what they reported and what they were asked to handle. Nothing else.
Granting access to one incident
When somebody genuinely needs a single restricted incident, an HR administrator grants access to that incident only. The grant is recorded with who gave it and when, it does not extend to anything else, and it can be withdrawn. That is the intended route — not changing somebody's role.
Reads are logged
Opening an incident is recorded, not just editing one. Nobody is accused of anything by looking, but "who has read this file?" is a question an investigation will eventually ask, and it can only be answered if the answer was being kept all along.
Reviews: the rule is the org chart
Reviews work the opposite way, deliberately. A manager sees their direct reports' reviews because the manager is the author. HR sees all of them. The subject sees their own — but only once it has been shared; before that, as far as they are concerned the record does not exist.
Private notes are narrower still: they stay with the reviewer and HR, and are withheld from the subject even after sharing and even on the underlying data request — not merely hidden on the page.
Your dashboard is yours alone
Every count, tile and list on the dashboard is filtered by the same rules. Two people signed in side by side will see different numbers, and that is correct — a count is itself a disclosure. "There are 3 restricted incidents" tells you something you were not meant to know.
What nobody can do
- Delete an incident or a review. There is no such button, for any role. Records are closed or archived; they are never removed.
- Edit history. Timeline entries and shared assessments are amended, never overwritten. Both versions stay.
- See a file by guessing its address. Every page, partial update and file download re-checks access on the server. A reference number that is not yours returns nothing whether you typed it or were sent it.
- Escape the audit trail. Administrators are logged exactly like everybody else.