Access, features and business-unit scope
The Employee workspace requires EMPLOYEE, PARTY and ORGANIZATION plus employee.view. Read access also uses the caller's permitted unit scope. Sensitive HR tabs have separate features and authorities and load their own data only when opened.
Permission matrix
| Work | Read authority | Write authority | Feature |
|---|---|---|---|
| Directory/master | employee.view | employee.create, employee.update | EMPLOYEE core |
| Current status | Master view | employee.manage | EMPLOYEE core |
| Employment, assignments, qualifications and status history | employee.employment.view | employee.employment.manage for record maintenance | EMPLOYEE core |
| Compensation | employee.compensation.view | employee.compensation.manage | EMPLOYEE_COMPENSATION |
| Emergency contacts, dependants and work authorisations | employee.personal.view | employee.personal.manage | EMPLOYEE_PERSONAL_RECORDS |
| Documents | employee.document.view | employee.document.manage | EMPLOYEE_DOCUMENTS |
| Benefits | employee.benefit.view | employee.benefit.manage | EMPLOYEE_BENEFITS |
Read and manage are separate. The browser needs the corresponding read authority to open a tab and management authority to show its add/edit actions. employee.manage changes status; it does not imply compensation or document access.
Lookup permissions are additional: Party selection, business-unit discovery, user discovery and employment/manager selection use their own endpoints. Enabling an HR feature does not grant permissions; granting permissions does not enable the feature. Use Administration for those changes.
Current visibility rules
An employee master is readable when any recorded employment or assignment belongs to an allowed unit. This check is not limited to today's effective period. Moving to another unit does not automatically remove visibility from a caller who still has access through historical records.
Employment reads are filtered by employer unit; assignment reads by assignment unit. Compensation and benefits require access to their linked employment's employer unit. Personal records, qualifications, documents and status history use accessible-employee checks plus their permissions. They are not independently scoped to the unit of an individual child record.
Example: An HR user can see Amira's master through an accessible assignment but may not see compensation linked to an employer unit outside that user's grants. An empty compensation list is not proof Amira has no pay agreement anywhere.
Creation and read checks differ
Some employee-linked support-record create services check tenant-owned employee existence rather than the full readable-employee gate used by later reads/updates. A successful create is therefore not proof that the caller has full visibility of that employee. Follow the approved employee-selection and area-permission process; this guide does not claim every create path enforces identical unit scoping. First employment separately validates its proposed employer unit.
Recovery
Check tenant, module/feature state, read/manage rights and unit grants before concluding data is missing. A not-found response can intentionally hide an out-of-scope employee. Do not use another tenant's IDs, invent grants or assume ADMIN bypasses these checks.
The first-employment chapter explains why a newly created unlinked draft can be absent from the directory. Broader historical visibility and creation/read asymmetry are documented current behaviours, not promises of current-assignment-only confidentiality or a completed onboarding wizard.