Connecting HR and Payroll in Seconds, Not Overnight
How a legacy batch integration was replaced with an event-driven architecture, connecting three enterprise applications through a shared employee data layer.
3 + 1applications and one canonical employee layerDelivered
99%processing reliabilityTeam-reported
Secondsinstead of hours or days to synchroniseTeam-reported
In production
October 2026
Legacy batch
Retired
Backbone
Kafka + Outbox / Inbox
→ or swipe to begin
✦ The challenge
Where it started
When employee information changes, several business systems need to reflect it. A new hire, promotion or contractual change can affect HR records, payroll calculations and onboarding workflows.
The existing integration relied on a legacy batch-processing system. Updates could take hours or longer to propagate, and investigating failed transfers was difficult. When records became inconsistent, HR teams often needed IT support to find problems and coordinate corrections.
The challenge was not to replace these applications. It was to make them work together reliably, with faster updates and greater visibility into what happened to each employee record.
Three applications to alignDelivered
Oracle HCMEmployee records, organisational structures and HR movements
TOTVS RMPayroll, leave and related employee information
SydleEmployee onboarding workflows
✦ Our approach
How we tackled it
A canonical Employee Database gives the connected applications one consistent reference. Instead of point-to-point integrations, each application talks through a dedicated adapter that transforms data into a common structure, validates business rules and propagates changes.
01
Map the data flows
Step 1
Identify which application owns each employee attribute.
02
Define validation rules
Step 2
Agree rules with HR stakeholders so incorrect or incomplete data is rejected before propagation.
03
Event-driven synchronisation
Step 3
Implement it, beginning with the onboarding workflow.
04
Run old and new in parallel
Step 4
Validate record consistency across both processes.
05
Retire the batch
Step 5
Switch off the legacy process once the replacement flows are confirmed.
The core integration went into production in October 2026, according to the delivery team's project records. Monitoring and ongoing improvements continue after deployment.
✦ Architecture
Conceptual diagram
Loading diagram…
Simplified from the technical team's architecture. Onboarding is shown as an input to the canonical layer; system-specific bidirectional flows depend on each integration contract.
Drag to pan · Ctrl/⌘ + scroll or pinch to zoom · click a block to trace its connections
✦ Technology
The stack, and why
Oracle HCMHR system of record for employees and movements.
TOTVS RMPayroll and leave.
SSydleEmployee onboarding workflows.
Apache KafkaAsynchronous, durable event backbone.
Hover or tap a technology to see why it is there.
All key engineering decisions
Technology / pattern
Why it matters
Canonical Employee Data Model
Standardises employee information and defines ownership of individual attributes, reducing conflicting updates
Kafka + Outbox/Inbox
Supports asynchronous communication and durable event processing, including recovery from delivery failures
Dedicated Integration Adapters
Isolates application-specific logic and allows integrations to be deployed and scaled independently
Idempotent Processing
Prevents duplicate events from causing repeated business operations during retries
Validation Before Propagation
Stops invalid records from spreading between connected applications
Integration Monitoring Dashboard
Gives HR teams understandable error messages, processing status and employee-level record comparisons
✦ Technical highlight
Reliability by design
The most important decision was to treat data consistency and failure recovery as core requirements, rather than relying only on faster data transfer.
Processing is at-least-once, combined with idempotency and deduplication, so transient failures are retried without repeating business operations. Events are ordered per employee while unrelated records are handled in parallel.
Don't lose itOutbox / Inbox keeps events safe between database update and publication.
Don't repeat itIdempotent processing makes retries harmless.
Don't spread itOwnership and validation stop bad data at the door.
Show itA monitoring view HR can read and act on.
The implementation also includes structured logging, health checks, authenticated HTTPS communication and centrally managed secrets.
✦ Evidence
The numbers
Where the seconds goModelled scenario
Illustrative midpoints of per-stage budgets: capture 1–2 s, validation 0.5–1 s, write 0.2–0.5 s, propagation 1–5 s (median budget about 3–8 s). Acceptance criterion P95 ≤ 30 s. Not a production measurement.
Manual corrections per month, by causeModelled scenario
Scenario on a hypothetical baseline of 120 corrections a month. Retries remove transient failures, validation removes invalid source data; human decisions remain. The actual reduction has not yet been quantified.
What 99% means in practiceModelled scenario
Changes in a month
5,000
20,000
100,000
Failures tolerated at 99%
50
200
1,000
Arithmetic from the definition of 99%: eligible changes successfully applied, including those recovered by automatic retries; changes needing manual intervention or rejected by data-quality rules count as failures.
✦ Results & impact
What we can say, and what we can't yet
The delivery team reports that the core integration entered production in October 2026 and that the legacy batch process was retired.
Metric
Result
Evidence
Enterprise applications integrated
3
Delivered
Shared canonical employee data layer
1
Delivered
Processing reliability
99%
Team-reported
Synchronisation
Seconds rather than hours or days
Team-reported
Legacy batch dependency
Retired
Delivered
Production go-live
October 2026
Delivered
The 99% refers to eligible changes successfully applied, including those recovered through automatic retries. It is reported by the engineering team; the measurement window and production event counts still require confirmation. The reduction in support effort and operational cost has not yet been quantified.
✦ What this project demonstrates
Principles that travel
Complex enterprise integrations can be modernised without replacing the applications a business already depends on. The value is not only moving data faster, but clear data ownership, designed-in failure recovery and integration behaviour that operational teams can see.
The same principles apply to CRM–ERP synchronisation, financial system integrations and employee lifecycle workflows.
Name an owner for every attribute
Design for failure, then for speed
Make integration visible to the people who use the data
Run old and new in parallel, then retire the old
How to read the badgesDeliveredTeam-reportedDocumented designMeasured · acceptance testModelled scenarioIn delivery
✦ Your turn
Still waiting for the overnight batch?
Let us make tomorrow morning happen in seconds. Tell us which two systems keep disagreeing and we will tell you who should own the truth.
TOTVS RMPayroll and leave.