←
WE People Settings · Access — who may see which class of data

Data class × role

As you confirmed it
Data class Operations Managers Payroll Admins Field leaders Employees — self
Compensation & pay history ✓ ✓ ✓ being confirmed being confirmed
Government identifiers — ✓ ✓ being confirmed being confirmed
Benefits & medical — ✓ ✓ being confirmed being confirmed
Discipline & HR notes ✓ ✓ ✓ being confirmed being confirmed
Enforced in the database. A missing checkmark is not a hidden menu item — it is a query that returns nothing.

Reading the table

The two columns that differ are the content of the answer
Operations Managers may see compensation and discipline records but not government identifiers or medical detail. That difference is why these classes are listed separately rather than collapsed into one “sensitive data” switch. One switch means either the strictest rule protects everything — and your operations managers lose access they need to do their jobs — or the loosest rule protects nothing.
Government identifiers get a stricter home, not just a stricter rule
They live in a separate part of the database with its own permissions. The account the application normally runs as holds no privileges there at all — reaching that data takes a different, narrower path that records every access. Which is also why the exclusion above is real rather than a setting somebody can flip by accident.
“Own record” is a second grant, not an exception
An employee must be able to see their own benefits — that is a row-scoped grant sitting alongside the org-wide one, on a different axis. It does not widen who may see everyone's. Medical detail read for display is still medical detail, and it is still audited.
Field leaders are marked “being confirmed” for a specific reason
The answer we have is that field leaders see some data for their own crew only, and some for everyone. That is a real and sensible answer, and it is not yet implementable — it says a per-field scope exists without giving a row of it. Guessing produces one of two failures: a field leader who cannot see their own crew's time, which makes the system useless to them, or one who can see everyone's, which is a confidentiality breach with a record proving we chose it. So it stays open, and what goes back to you is this table crossed with own / crew / division / everyone, to tick line by line.
Employee self-access is unstated for three of the four rows
Nothing has been confirmed about whether an employee sees their own pay history, their own identifiers, or notes written about them in this system. We are not defaulting those to yes because it seems friendly, or to no because it seems safe. They are unanswered, and unanswered is a state we are willing to show you.

The gap between this table and sign-in day

Deciding who may see what is done. Recognising who is who is not. Of the four role names above, only Payroll has a matching group in your Microsoft directory today. There is no HR group at all, no operations-manager group, and your field leaders are spread across several groups rather than collected into one.

This does not weaken anything in the table — your answer about access stands. What is missing is the mechanism that tells the software, at sign-in, which of these rows applies to the person arriving. Creating those groups is short work for your IT team and it needs to start before go-live, not at it.

And one fact that raises the stakes on the whole table 155 field employees will reach this system on their own personal phones, which nobody manages and nobody can wipe. That is the normal state, not an exception to handle later — and it is why the sign-in model and this matrix have to be settled together rather than one after the other.
What this screen teaches. Access here is a property of the data, not of the screen. Every checkmark above is a grant in the database, and every dash is the absence of one — so a report, an export, an interface response and a page all give the same answer, because there is only one answer to give. See it refuse a field →