WE People — Report builder

Fields

3 of 8 selected

General

Permitted for your role

Name Employee full name Employee ID Your Sage payroll identifier — we never mint our own Division North or South Classification Position as it appears on the employee record Hire date Drives service length and leave eligibility Licence type Apprentice · Journeyman · Master — tenant reference data Licence expiry The date the 60 / 30 / 7 reminders count back from Shirt size A trade field you already keep — and a custom field, not a product column

Restricted

Not permitted for your role

Compensation and pay history Operations Managers · Payroll · Admins Locked Birth date Payroll · Admins Locked Government identifiers Payroll · Admins — Operations Managers explicitly excluded Locked Bank routing and account details Payroll · Admins Locked Benefits and medical detail Payroll · Admins — plus each employee's own record Locked Discipline and HR notes Operations Managers · Payroll · Admins Locked

The verdict depends on who is asking. Tick a restricted field and this panel shows the answer for the seat you are sitting in: for most seats a refusal — from the database, not the screen — and for the payroll & system admin an audited read that goes on the record. Same screen, same query, different seat, different answer.

Custom fields appear here automatically once classified — every field must be classified before it can ever appear. There is no default classification and no “decide later”. The person who creates a field chooses general or restricted at the moment they create it, and that choice decides which part of the database the values physically live in.

Preview

5 of 185 rows

Five synthetic rows, rebuilt from your selection. Nothing is queried and nothing is stored — but the shape is real: a saved report holds the list of fields you picked, never a copy of the results and never a resolved list of columns. When somebody else opens it, it resolves against their rights, not yours.

Why the lock is not in this browser

Hiding a field in the interface protects nothing. The same value comes back through an export, an interface response, or a report somebody builds a slightly different way. So the restriction lives one layer down: restricted data sits in a separate part of the database, and the account this application uses to run your reports has no privileges there at all. If every line of our code were wrong, the query would fail with a permission error instead of returning a column.

One honest limit

We can prove that no field classified as restricted ever reaches a role that may not see it — that is a property of the database, and it is testable automatically every time the code changes. We cannot prove that nobody ever typed a pay figure into a general-purpose notes field. That gap is closed by governance rather than architecture: classification is mandatory when a field is created, changing a field's classification physically moves the data and is recorded, and making restricted data visible again needs a second approval.

One related item is worth flagging now rather than at handover: your BambooHR custom fields have accumulated over years, and any of them could hold something sensitive. Every inbound field gets classified before import, and an unclassified field stops the import rather than defaulting to general.