People-Ops Integration Architecture: A Reference Pattern

60-Second Summary

HRIS is the system of record; everything else integrates to it, not to each other.
Three integration tiers: real-time events (joiner/leaver), nightly syncs (master data), and warehouse extracts (analytics).
Adopt one identity (employee ID) as the join key everywhere. Never let department names be a join key.
Build an integration backbone (iPaaS) before the third integration, not after the tenth.

Most People-ops integration problems are misdiagnosed as tool problems and end up as expensive replacements that don't solve anything. The real issue is almost always architectural: no system of record, no consistent identifier, no event model, and no integration backbone. Fix the architecture and most of the 'tool problems' disappear.

Five architectural principles

One system of record (the HRIS) for employee master data. Everything else reads from it.
One employee identifier used by every system. Email is a bad identifier; employee ID is good.
Event-driven for joiner/mover/leaver; batch-sync for everything else.
Integration backbone (iPaaS or middleware) between systems, not point-to-point.
Analytics flows go to a warehouse, not from system to system.

Reference topology

A reference People-ops architecture

HRIS (system of record)
Master employee data, org structure, employment events
iPaaS / integration layer
Workato / Tray / Boomi / MuleSoft
Downstream systems
ATS, payroll, learning, engagement, IT provisioning, finance
Data warehouse
Snowflake / BigQuery / Databricks — analytics & reporting
BI / dashboards
Looker / Tableau / Power BI

The three integration tiers

Tier	Use case	Latency	Mechanism
Tier 1 — Events	Joiner provisioning, leaver de-provisioning, role changes that trigger access	Seconds to minutes	Webhooks or event bus
Tier 2 — Master data sync	Department, manager, cost centre, location updates	Hourly to nightly	API pulls or scheduled exports
Tier 3 — Analytics	All historical data for BI and people analytics	Daily to weekly	ETL / ELT to warehouse

The mistake almost everyone makes: trying to do everything in Tier 1. Real-time integration is expensive and fragile; reserve it for the cases where minutes matter (access provisioning especially).

When to adopt an iPaaS

Below ~5 active integrations, point-to-point is manageable. Above that, you need a backbone. The economic break-even is usually at integration #3 — by integration #6 the team without an iPaaS is paying it in firefighting and broken syncs they don't know about. Tools that fit at different scales: Zapier / Make for the smallest companies, Workato / Tray for mid-market, MuleSoft / Boomi for enterprise.

Common anti-patterns

Anti-pattern

ATS writes directly to payroll
Email used as the join key
Real-time syncs everywhere
Each new tool gets its own data dump
Analytics happen by exporting CSVs from each system

Pattern

ATS writes to HRIS; HRIS syncs to payroll
Employee ID used everywhere; email is metadata
Real-time only for events; batch for master data
Tools subscribe to a single feed via the backbone
Warehouse pulls from each system; BI queries the warehouse

The 'integration debt' tax

Companies that skip the architecture step pay it back later in: failed audits (people who left months ago still have access), broken downstream analytics (numbers don't match across reports), and HRIS replacement projects priced at $5–15M because the integrations are so tangled the replacement has to re-do all of them.

The maturity ladder

Level 1 — point-to-point chaos. Level 2 — iPaaS adopted, integrations standardised. Level 3 — event-driven architecture for joiner/mover/leaver. Level 4 — analytics warehouse separated from operational systems. Level 5 — self-service integration patterns for new tool onboarding. Most companies are at Level 1–2; the goal is Level 4 by year 3 of a serious People-ops investment.

Written by Pawan Joshi.Sources cited inline.

First published 23 Jun 2026See site changelog →