←
My Info Alex Voltner · WE-4417

Alex Voltner

Journeyman electrician · WE-4417
North division
You are viewing this as Riley Ohm · field supervisor Some rows below are masked. That is not the screen being coy — it is the database returning nothing for a role that is not permitted to read them. Change the viewer and the same page renders different rows, because the permission lives one layer beneath the page.

Personal

Employee-editable
Legal name
Alexander James Voltner
Preferred name
Alex
Home address
4820 Copperline Way, Apt 6
Ogden, UT 84403
Mobile
(555) 555-0147
Personal email
a.voltner@example.invalid
Work email
alex.voltner@example.invalid
Shirt / jacket
L / XL

Legal name and preferred name are two fields, not one. Payroll documents and the I-9 must carry the legal name; the directory, the crew list and the app greeting should carry the one he answers to. Collapsing them into a single field forces a choice that gets somebody’s paperwork rejected or somebody’s name wrong every day.


Restricted fields

Separate schema
Date of birth Hidden. Visible to Payroll and Admins only; enforced by the database, not the screen.
Government identifiers Hidden. Visible to Payroll and Admins only; enforced by the database, not the screen. Operations Managers can see compensation and cannot see this — two different permission lists, deliberately not merged into one “sensitive” bucket.
Identity documents on file Hidden. Scanned identity documents collected at onboarding live in restricted storage with their own access rules and their own audit trail. Even the count is withheld from this role.
EEO self-identification Hidden. Collected for reporting, never used for routing, approval or any decision the software makes.

Direct deposit

2 accounts
Account 1 · checking 60% of net pay
Account 2 · savings 40% of net pay
60% · account 140% · account 2

Notice what is visible and what is not. That the split is 60/40 across two accounts is structure — payroll needs it, and it is not a secret. The account numbers and the amounts are, and they stay masked for this role. Bank details are the reason this data sits in a separate database schema that the ordinary application account holds no privileges on at all.

Alex’s own view is different An employee reading their own record is a second, row-scoped grant alongside the role grant — two grants, not one exception. What Alex may change is narrower still, and every change he proposes waits for approval. See the self-service path →

Twelve sections, and where they are

Your scope document lists twelve sections in this record. Nine of them are the tabs above, with Discipline and Notes shown together because in your company the same three roles see both. The remaining two — Onboarding and Offboarding — are checklists driven by the admin settings and have their own screen.

See the onboarding checklist → · See the offboarding checklist →

Benefits and dependents appear here as a read-only view of your bswift data. Open enrolment stays in bswift; whether employees can also make changes from here is being confirmed.

What this screen teaches. Sensitivity is not one setting. Compensation is visible to three roles; identifiers and bank details to two; discipline to three again — and none of that is expressible as a single “sensitive data” switch. So the rules are written per data class, they are enforced by the database rather than by this page, and every read and change of a restricted field is recorded.