HR system integration: what a HR integration has to carry, and what quietly does not travel between two products

Specifying an integration properly

1. List the events, not the fields. Joiner, leaver, change of pay, change of manager, change of cost centre, change of hours. Each is an event with a date, and an integration that syncs fields nightly will get the dates wrong on all of them.
2. Decide which system is authoritative per field. Write it down field by field. Most integration failures are two systems both believing they own the same value, and the symptom is a change that keeps reverting.
3. Agree what happens on failure. A dropped message with no alert is the worst outcome and the most common. Ask where failures surface, who sees them, and whether a replay is possible.
4. Test an effective dated change. Enter a promotion effective next month and watch when the downstream system receives it. On entry is wrong for payroll and right for planning, so the behaviour has to be deliberate rather than incidental.

What a HR integration usually carries and what it drops

The person, the job and the pay usually travel. Cost centre changes, future dated records and anything in a custom field usually do not, because the standard connector was built for the standard object.

The result is a small set of changes that have to be made twice, and nobody writes them down. List them during implementation and give them an owner, because they are the source of most of the discrepancies found at year end.

Identity is the integration that matters most

Where the HR record drives account creation and removal, the leaver event is a security control. A leaver whose accounts remain active is a finding, and the gap is almost always a failed or delayed integration rather than a forgotten process.

Ask for the timing explicitly: on the leave date, on the day the record is updated, or nightly. The difference between them is the exposure window, and it is a number you can put in a policy.

Files, connectors and APIs

A nightly file is a legitimate integration and it should be recognised as one, with a schedule, an owner and a failure alert. What it cannot do is carry events with effective dates, so any process depending on those has to run from the source system.

A maintained connector is better and a documented API is best, because the third lets you fix what the second does not cover. Judge the documentation rather than the marketing: public docs, a sandbox and write access to the objects you care about.

Common questions

Is an integration always worth building?

Only where the same change would otherwise be entered twice regularly. A rare manual step with a named owner is cheaper and more reliable than a fragile connector nobody maintains.

Who should own an integration?

A named person in the team that owns the source data, not the team that owns the pipe. Failures are almost always about meaning rather than transport.

How do we test one?

With the awkward cases: a rehire, a transfer, a future dated change and a leaver on the same day as a pay change. Standard cases pass in every product.

What should be in the vendor agreement?

Which integrations are maintained, what happens when the other vendor changes their interface, and what support response applies to an integration failure as opposed to a product failure.

Coverage by country

• Employer of record vendors covering Singapore
• Employer of record vendors covering Mexico
• Employer of record vendors covering Spain
• Employer of record vendors covering Colombia
• Employer of record vendors covering United Kingdom
• Employer of record vendors covering France
• Employer of record vendors covering Hungary
• Employer of record vendors covering New Zealand