Your HCM Unified the Data. The Work Is Still Scattered.

Start honest. For years, people data was scattered across a payroll system, a benefits system, a recruiting tool, a performance module, and a drift of spreadsheets. The HCM suites fixed that. Pulling HR — and increasingly finance — onto one system of record genuinely reduced fragmentation: one employee object, one org model, one authoritative place to ask who reports to whom and what they are paid. That is not marketing. It is a structural improvement, and buyers were right to pay for it.

The layer built on top is real too, and it deserves to be named plainly rather than dismissed:

• Skills intelligence — a live skills graph that surfaces who could move into an opening and where a capability gap is forming is genuine signal, not a dashboard toy.
• Self-service — letting employees and managers file their own changes offloads a mountain of HR toil that used to land in a queue.
• HR copilots — they answer policy questions, summarize a career history, and draft a job description well, and that saves real time.

None of this is what I want to challenge. Concede it fully — because the wedge is not that the suites did too little. It is that they unified the wrong noun.

Single source of truth is a claim about data. It says there is one authoritative record of the employee and one view everyone shares. Within the HR domain, that is true and valuable. But almost no people process lives inside the HR domain. Onboarding a new hire is not an HR event; it is an IT provisioning event — accounts, entitlements, a device — a finance event — payroll enrollment, cost-center allocation — a facilities event — badge, seat — and a manager event, all triggered by one hire. A reorg is a compensation change and an access change and a reporting-line change at once. A transfer touches every one of those systems. An offboarding is the same list run in reverse and under a clock, where a single missed step is a live security exposure.

In each case the HR system does what a system of record does: it updates the record and generates tasks. Then it hands those tasks off — to a ticket queue, a provisioning tool, a payroll run — over an integration, and waits for a status flag to come back. The unified view shows you a tidy checklist. Underneath it, the work is executing in systems the HR platform can describe but not run. That is an integration story wearing a platform story's clothes.

For a CIO and a CISO, the handoff is not a UX detail — it is where control degrades. Each downstream system enforces its own entitlements and keeps its own log. The approval that actually matters — should this person hold this access, at this level, given their new role — is captured in one tool and executed in another. Segregation of duties across that seam becomes a reconciliation exercise. And the audit trail for did onboarding grant exactly the right access and nothing more does not exist as one object; it has to be reassembled after the fact by stitching timestamps out of systems that log differently.

So the unified record buys you a clean answer to what is true and a murky answer to how it came to be true. For people processes — where the how is access, money, and compliance — that second gap is the expensive one.

Be fair about the strongest counterexample. One class of workforce cloud natively combines HR and IT, and during onboarding it really does provision apps and devices — not merely assign a task to provision them. That is meaningfully more execution than a pure system of record, and anyone who has watched a new hire idle for three days waiting on a laptop understands why it sells.

But look at the shape of it. That platform automates provisioning within its own suite's domains — the apps and devices it was built to manage. It is records plus a set of point automations, bounded by the vendor's own footprint. The moment the process reaches finance, facilities, procurement, or any function outside that footprint, you are back to integrations and handoffs. Unifying the record and automating provisioning inside one suite is a real improvement. It is still not the people process running as one governed workflow on the same fabric that also runs finance, facilities, and every other enterprise process — with one inline governance model and one audit across all of it.

Entroid starts from a different primitive. It does not bolt a workflow feature onto an HR record; it models every enterprise process — people processes included — as a composition of five primitives on one shared fabric: Deterministic Workflows that carry governance inline (entitlements, approvals, segregation of duties, thresholds), Intelligence Orchestration, Atomic Agents with human-in-the-loop as a first-class step, Functions, and Connectors — the only primitive that touches an external system. The ES People modules — Workforce, Recruitment, Time and Leave, Compensation, Growth, Engagement — sit on that fabric, not beside it.

What that changes is architectural, not cosmetic. A hire-to-onboard is not a record update plus a portal plus a fan-out of downstream tickets. It is one Deterministic Workflow that spans HR, IT provisioning, finance and payroll, facilities, and manager tasks — running on the same runtime as finance and every other process. The access grant, the device order, the payroll setup are steps inside that one workflow, executed as governed actions. Connectors reach into your existing estate to do the actual provisioning — so this is emphatically not a rip-and-replace or a zero-integration fantasy. The difference is that integration is demoted to a governed primitive inside one process, rather than being the substance of the process itself.

Because the workflow is the record, the properties you used to reconstruct now hold by construction:

• Governance is enforced, not documented — the entitlement and approval checks run inline, at the step that grants the access, in the same runtime, rather than in a separate tool the granting system trusts on faith.
• The audit is one object — every action across HR, IT, finance, and facilities writes to a single immutable per-action trail, so did onboarding grant exactly the right access is a query, not a forensic project.
• Human judgment is a step, not a detour — where a decision needs a person, the pause is part of the governed workflow, not an email running alongside it.

Consider a transfer, illustratively. An employee moves between business units. On the fabric that is one workflow: it revalues compensation against the new band, requests exactly the manager and finance approvals the thresholds demand, revokes the old entitlements and grants the new ones through Connectors into the identity systems, resets the reporting line, and moves the cost-center charge — each step gated by the same policy and written to the same trail. There is no window in which the person carries both the old access and the new role, because there is no seam where one system has finished and the next has not yet begun. The reconciliation that used to close that gap is simply not needed, because the gap never opens.

To be precise about scope: this is an architectural property of how ES is designed, not a war story about a shipped deployment, and the example above is illustrative. The claim is structural. When the people process executes as one governed composition on the same fabric as finance and facilities, the record and the work stop being two things you keep in sync. They become the same object.