HR Core and Organisational Management

HR data is the most privacy-sensitive data in the ERP, and the most politically sensitive. Handle it accordingly.

The core objects 

Person             a human being (may have several employments over time)
 └── Employment    a contract with a legal entity
      └── Assignment   a position held, with dates
           └── Position    a specific job slot in the org
                └── Job     the generic role (Software Engineer II)
                     └── Org unit   the department

The distinction that matters: person vs employment vs assignment. A rehired employee is the same person with a second employment. A person on secondment holds two assignments. Modelling employment as a column on a person table breaks on the first rehire.

Effective dating — the defining HR pattern

Almost every HR attribute is time-sliced:

employee_assignment
  person_id  position_id  cost_center  manager_id  fte   valid_from   valid_to
  1001       P-1200       CC-SALES     2004        1.0   2022-01-01   2023-06-30
  1001       P-1450       CC-SALES     2004        1.0   2023-07-01   2024-12-31
  1001       P-1450       CC-MKT       2088        0.8   2025-01-01   9999-12-31

Every query needs an as-of date. “Who reported to Karim in March 2024?” and “Who reports to Karim today?” are different queries against the same table.

Retroactive changes are normal, not exceptional: a promotion approved in April, backdated to January. This means payroll must recalculate retroactively, and the reporting hierarchy for a past period must be reconstructible. Design for it from the start.

Organisational management 

Organisational unit (department)
 ├── reports to another org unit  (the org hierarchy)
 ├── contains positions
 ├── has a chief position (the manager)
 ├── linked to a cost centre
 └── effective dated

Positions vs jobs:

  • Job — the generic role: “Accountant”, with a grade, a job family, and a description
  • Position — a specific slot: “Accountant, Dhaka Finance, position 4471”, which may be filled, vacant, or planned

Why positions matter: headcount planning and budget are per position. A vacant position is a budgeted, approved slot. Companies that track only employees can’t tell you their approved headcount.

Relationships in the org model form a graph: reports-to, belongs-to, is-manager-of, describes, holder-of. Matrix organisations need multiple simultaneous hierarchies (line manager, project manager, functional manager) — which means a single manager_id column is insufficient in most large companies.

Employee master data

Group Contains Sensitivity
Personal Name, DOB, gender, nationality, marital status High
Contact Address, phone, email, emergency contact High
Identity National ID, passport, tax number, work permit Very high
Employment Hire date, contract type, probation, notice period Medium
Organisational Position, org unit, cost centre, manager, location Low
Compensation Salary, grade, allowances, bonus Very high
Bank Account details for payroll Very high — fraud target
Time Work schedule, leave entitlement, balances Medium
Benefits Insurance, pension, dependants Very high
Development Skills, qualifications, appraisals, training High
Health Medical, disability, occupational health Special category under GDPR

Privacy requirements

Under GDPR (and equivalents: India DPDP, Brazil LGPD, China PIPL, California CPRA):

  • Lawful basis for each processing purpose — for employees this is usually contract or legal obligation, rarely consent (consent is considered unfreely given in an employment relationship)
  • Special category data (health, race, religion, union membership, biometrics) needs stronger justification and stricter controls
  • Data minimisation — don’t collect what you don’t need
  • Retention limits — delete or anonymise after the statutory retention period
  • Right of access — an employee can demand everything you hold about them, and you must be able to produce it
  • Right to erasure — limited for employment records, but real for some data
  • Cross-border transfer restrictions — this is why global HR systems have regional instances
  • Works councils — in Germany, Netherlands, France and elsewhere, employee representatives must approve systems that monitor employees. This can block a deployment.

As a developer: field-level access control, encryption at rest for sensitive fields, audit logging on every read of compensation and health data, and masked test data are minimum requirements. Copying production HR data into a dev environment unmasked is a reportable breach in most jurisdictions.

Employee lifecycle 

Requisition → Recruit → Offer → HIRE → Onboard → Work
                                          │
              ┌───────────────────────────┼──────────────────┐
              ▼                           ▼                  ▼
         Transfer / promotion       Leave of absence    Performance
              │                           │                  │
              └───────────────────────────┼──────────────────┘
                                          ▼
                                      TERMINATE
                                          │
                                   Offboard → Archive/anonymise

Each transition is an action with its own required data, approvals, and downstream effects:

Action Downstream effects
Hire Payroll record, IT accounts, access badge, benefits enrolment, cost centre assignment
Transfer Cost centre change, manager change, possible pay change, access rights change
Promotion Grade, salary, position, effective date, retroactive pay
Leave Payroll suspension or reduced pay, leave accrual pause, backfill
Termination Final pay, leave encashment, notice period, asset return, access revocation

Termination is where most organisations fail an audit. A terminated employee whose ERP and system access remains active is a standing finding. The HR termination event must trigger automated deprovisioning — this is the single most valuable HR↔IT integration you can build. See Security Model and RBAC.

Headcount and FTE 

Headcount:  number of people
FTE:        full-time equivalent  (0.5 for a half-time employee)

12 people, 3 of whom are 0.5 FTE  →  headcount 12, FTE 10.5

Both are needed. Budget is in FTE; workspace, licences, and benefits are per head. Contingent workers (contractors, agency, outsourced) usually count in neither, which is why “why does the office have more people than the org chart?” is a recurring question. Model contingent workers explicitly.

HR ↔ Finance integration

Flow Purpose
Cost centre assignment Payroll cost posts to the right department
Payroll journal Salary, tax, benefit accruals into the GL
Time to project/order Labour cost onto cost objects
Headcount for allocations Driver-based overhead allocation
Bonus and leave provisions Period-end accruals
FTE for budgeting Driver-based planning

HR ↔ Identity integration

The joiner-mover-leaver (JML) process is where HR meets IAM:

HR system (source of truth for identity)
    │  hire / transfer / terminate events
    ▼
Identity governance (SailPoint, One Identity, Saviynt, Entra ID Governance)
    │  provision / modify / deprovision
    ▼
Target systems: ERP roles, email, VPN, building access, SaaS apps

Key requirements: HR must be the authoritative source; events must be near-real-time for terminations; and there must be a reconciliation job that finds accounts with no matching active employee (orphan accounts). Orphan account reports are a standard audit request.

Reporting

  • Headcount and FTE by org unit, location, contract type — with a trend
  • Turnover: voluntary vs involuntary, by tenure, by manager, by department
  • Regretted vs non-regretted attrition — losing your best people is a different problem from losing your worst
  • Time to hire, cost per hire, offer acceptance rate
  • Absence rate, Bradford factor
  • Diversity metrics — subject to strict rules on what may be collected and how it may be reported; in some jurisdictions aggregation thresholds are legally mandated to prevent re-identification
  • Span of control, org depth
  • Gender pay gap reporting (mandatory in the UK, EU, and elsewhere)

Developer rules

  1. Effective-date everything. Every HR query has an as-of date.
  2. Person ≠ employment ≠ assignment. Model all three.
  3. Retroactive changes are normal. Design payroll and reporting for them.
  4. Field-level security, not just object-level. Not everyone who can see an employee record may see their salary.
  5. Audit every read of compensation, health, and identity data — not just writes.
  6. Mask HR data in non-production. Always. No exceptions.
  7. Termination triggers automated deprovisioning, with a reconciliation report for orphans.
  8. Involve HR and, where applicable, the works council before building anything that monitors employees.
  9. Retention and deletion policies must be implemented, not just documented.

Next