Who sees what
mizuiro’s job is to keep the right information in front of the right people. Every record - a touchpoint, a performance review, an expense report - has explicit rules about who can see it, who can edit it, and who can open the detail page. This page is the reference for how those rules work, written for managers who need to reason about confidentiality.
The short version: managers see everything in their company. Supervisors see what’s relevant to the people they look after. Employees see their own records and the things that have been explicitly shared with them. What “relevant to the people they look after” means depends on your supervisor scope setting from the setup wizard.
You picked one of these at setup; it can’t be changed afterwards.
Assigned scope is narrow. A supervisor only acts on people in the teams they lead. The Sales supervisor doesn’t see the Engineering team’s expense reports, training records, conferences, or touchpoints. Performance documents (reviews, concerns, improvement plans, written warnings) and incidents are private to the supervisor who created them - even another supervisor on the same team can’t read the contents.
Shared scope is wide. Every supervisor can see every record in the company. This works for smaller organizations where the supervisor layer functions more like a co-management layer with the primary manager.
Across both scopes, managers always see everything. And employees only ever see their own records, plus anything you’ve explicitly shared with them (e.g. a performance review you toggled to be visible to its subject).
The grid below assumes a module is turned on. If a module is off for your company, nobody sees its records.
| Module | Manager | Supervisor (assigned) | Supervisor (shared) | Employee |
|---|---|---|---|---|
| Employees (directory) | Everyone | Everyone | Everyone | Everyone, but a coworker’s card shows directory fields only - name, title, team, @mention, email. Employment status, employee number, hire date, probation and other employment dates, phone, last login, and scheduled status changes are all hidden. Their own card shows everything. |
| Presence calendar | Everyone | People on their teams | Everyone | Their own (via mobile dashboard) |
| Touchpoints | All | Touchpoints they conducted or that involve their team | Everyone | Their own non-private touchpoints, when employee visibility was on at creation |
| Meetings (freeform minutes) | All | Only the meetings they wrote | Only the meetings they wrote | Never |
| Tasks | All except other people’s self-assigned (private notes) | Their team’s tasks + their own + tasks they created | All except other people’s self-assigned | Tasks assigned to them |
| Expenses | All | Their own + their team’s | Everyone | Their own |
| Conferences | All | Their own + their team’s | Everyone | Their own |
| Training | All | Their own + their team’s | Everyone | Their own |
| Awards | All | Their team’s | Everyone | Their own |
| Kudos | All | Their team’s | Everyone | Their own |
| Performance reviews | All | Reviews they conducted | Everyone | Reviews about them that the manager has explicitly shared |
| Performance concerns | All | Concerns they recorded | Everyone | Never (manager-only sensitive HR) |
| Improvement plans (PIPs) | All | PIPs they created | Everyone | Their own plan (read-only, once communicated; no linked evidence or manager notes) |
| Written warnings | All | Warnings they issued | Everyone | Their own (read-only, with acknowledgement) |
| Incidents | All | Incidents they filed | Everyone | Never |
| Polls | All | Polls targeting their teams + polls they’re invited to | Everyone | Polls targeting their teams + polls they’re invited to |
| Kikubari (people insights) | All | Their team’s | Everyone | Their own (read-only) |
| Contacts | Everyone | Everyone | Everyone | Everyone (company-wide directory) |
| Reports | All company data | Restricted to their teams in assigned scope | All company data | No access (manager / supervisor only) |
The History tab is a chronological audit of HR events for one person: profile changes, status changes, performance concerns, PIPs, written warnings, and incidents. It’s designed to give whoever is looking after the person a complete picture.
To support that, the History tab always shows every event the employee is associated with, even ones the viewer doesn’t have read access to.
What changes per viewer is whether each event is clickable. If a supervisor in assigned scope is looking at a teammate’s history and sees a performance concern recorded by a different supervisor, the row appears - they can see the date, the type of event, and who filed it - but the reference number is shown as plain text rather than a link, and the severity badge is hidden. Hovering shows “You don’t have access to this record.”
This is deliberate. A complete audit picture matters more than strict hiding, and the protected content (the specifics inside the record) stays unreachable.
The presence calendar follows the same principle: a touchpoint badge that the viewer can’t open renders as a static violet pill rather than a link. Incident badges are always non-clickable by design.
Observer accounts are a special kind of manager account with read-only access. An observer sees everything a manager would see - no records are hidden - but every write action is blocked at the server level. They can browse, search, export, and review, but they can’t add, edit, delete, or approve anything.
Observers exist so a business owner, accountant, or board member can stay across what’s happening without needing operational permissions.
If you’re trying to figure out whether someone on your team can or can’t see a specific record, the quickest check is to ask them to look. If they can see the record, the access rules allowed it. If they can’t, the rules excluded them. The grid above is the intent, and mizuiro enforces it everywhere: a record someone isn’t allowed to see is never put in front of them in the first place, not just hidden in the interface.
If you think you’ve found a case where someone is seeing something they shouldn’t, email support and tell us how to reproduce it. We treat visibility bugs as security bugs and respond fast.