Before you configure a single connector or sign an API licence, there are ten questions you should be able to answer. Most teams skip straight to question seven and pay for it later.

HR technology rarely fails because a platform can't do the job. It fails in the gaps between platforms: the payroll file that didn't pick up a mid-month promotion, the leaver who still has system access, the name change that lives in three versions across three systems.

Those gaps are getting wider, not narrower. MuleSoft's 2026 Connectivity Benchmark Report, a survey of 1,050 IT leaders, found the average organisation now runs 957 applications — and only 27% of them are connected. IT teams report spending around 36% of their time designing, building and testing custom integrations, and 26% of IT projects landed late in the previous year.

The instinct is to jump straight to the technical question: real-time or batch, API or flat file, middleware or native connector. That's question seven. It matters enormously — but only once you've answered the six before it. Here's the full checklist, and why each question earns its place.

Discovery & Scoping

1. What business problem does this integration solve?

Not the technical one — the human one. "Sync the ATS with the HRIS" is a task. "New starters can't log in on day one because their record reaches IT three days late" is a problem.

Framing it this way gives you something to measure after go-live: fewer day-one access failures, fewer manual payroll corrections, faster offer-to-contract. It also stops scope creep. Every field someone wants to add can be tested against a simple question: does it help solve the problem we agreed?

2. Which systems are involved, and who owns each one?

List every system the data touches, not just the two at each end. That usually means the HRIS and ATS, but also payroll, identity and access management, benefits providers, learning platforms and any middleware in between.

Then name an owner for each — a person, not a department. When a field mapping needs signing off, or a vendor pushes an update that changes an API, you need someone who can say yes. "IT owns it" is how integrations end up owned by nobody.

3. What is the agreed source of truth for each data entity?

For every data entity — legal name, job title, cost centre, manager, salary, start date — one system must be the master. Everything else reads from it.

Without that agreement, two systems will eventually disagree, and the integration will faithfully copy the wrong answer everywhere. Gartner research puts the average cost of poor data quality at $12.9 million a year per organisation. Much of that starts with nobody deciding whose version counts.

A simple matrix does the job. Put it in your design document and get it signed off before anyone builds a mapping:

Example only — your mapping will depend on your estate.

Data & Compliance

HR integrations move some of the most sensitive data an organisation holds. Under UK and EU GDPR, connecting two systems isn't just plumbing — it's a new processing activity, with obligations attached.

4. What personal data is in scope, and what is the lawful basis under GDPR?

Start with data minimisation: which fields does the receiving system genuinely need? A learning platform probably needs name, role and manager. It almost certainly doesn't need salary, bank details or date of birth. Every field you don't send is a field you never have to protect, map, test or erase.

Then document the lawful basis for each flow. In employment, the ICO steers employers away from consent: because of the power imbalance between employer and worker, consent is unlikely to be freely given. Contract, legal obligation or legitimate interests are usually more appropriate. If special category data is involved — health, diversity monitoring, trade union membership — you also need an Article 9 condition on top of the Article 6 basis.

5. Are Data Processing Agreements in place with every vendor involved?

Every vendor processing personal data on your behalf needs a contract that meets Article 28. The ICO lists the minimum required terms: processing only on your documented instructions, confidentiality, security, rules on sub-processors, help with data subject rights, end-of-contract deletion or return, and audits.

The gap usually sits in the middle. Your HRIS and payroll providers will have DPAs. The iPaaS or middleware vendor that sits between them — and briefly holds every record in transit — is often forgotten. So are its sub-processors, such as hosting providers.

6. How will Subject Access Requests and Right to Erasure requests be handled end-to-end?

Integration multiplies copies. When an employee submits a SAR, you must respond within one month of receipt, extendable only for complex cases. That clock doesn't pause while you work out which six systems hold their data.

Erasure is harder still. If you have disclosed personal data to others, the ICO says you must contact each recipient and tell them about the erasure, unless that's impossible or disproportionate. Worse, a live integration can quietly undo the deletion by re-syncing the record from an upstream system the next night.

Build the answer into the design: a data map showing where each field lands, a documented erasure sequence that starts at the source of truth, and retention rules applied consistently across every connected system. Your DPO should sign this section off, not just read it.

Technical Design

7. Real-time, near-real-time, or batch?

Here's the question everyone wants to start with — and the one that's easiest to get wrong without questions one to six. The right answer comes from the business need, not from what the vendor demo made look impressive.

A payroll feed almost never needs to be real-time — it needs to be complete and correct by the cut-off. Revoking a leaver's system access, on the other hand, can't wait for tonight's batch. Many estates need a mix, and that's fine. What isn't fine is paying for real-time everywhere because nobody asked what "timely" actually means.

8. How are conflicts and errors handled — and what happens when it breaks?

It will break. APIs time out, vendors throttle requests, certificates expire, and someone renames a picklist value on a Friday afternoon. Microsoft's architecture guidance puts it plainly: in cloud services, transient faults should be expected, and systems should be designed to handle them gracefully.

Your design document needs a clear answer to each of these:

• Retries: which errors are retried automatically, how many times, and with what delay?
• Conflicts: when two systems disagree, which wins? (Question three should already have answered this.)
• Failed records: where do they go, and can they be replayed without creating duplicates?
• Alerts: who gets notified, through which channel, and within what timeframe? A named person, not a shared inbox nobody reads.
• Fallback: if the integration is down on payroll cut-off day, what's the manual workaround — and who has tested it?

The most dangerous integration isn't the one that fails loudly. It's the one that fails silently, skipping a handful of records every night while the dashboard stays green.

Governance & Testing

9. Is there a UAT plan that covers real-world edge cases?

Happy-path testing proves the integration works for the employee who joins on the first of the month, full-time, on a permanent contract, and never changes anything. That employee is not your workforce.

Your UAT plan should include, at minimum:

• Leavers: including retrospective leavers, leavers with final pay adjustments and people who leave and are re-hired
• Role changes: promotions, transfers between legal entities, manager changes and backdated changes
• Part-time and variable-hours workers: FTE changes, multiple concurrent contracts, term-time working
• Name and identity changes: marriage, divorce, transition, and characters that break older systems (apostrophes, hyphens, accents)
• Timing edge cases: changes submitted after payroll cut-off, effective-dated records, and mid-month starters

Test with realistic volumes and representative data — anonymised or synthetic where production data would breach question four. And make sure HR tests it, not just IT. The people who know that Sinéad O'Brien-Müller exists are the people who should be checking her record arrived intact.

10. Who owns post-go-live monitoring, and how are changes managed?

Go-live isn't the finish line; it's the point where the integration starts earning its keep. Someone must own its health: reviewing error logs, reconciling record counts between systems, and acting on alerts.

Then there's change. SaaS platforms don't stand still. Workday, for example, ships major releases twice a year, in March and September, and well-run customers review and regression-test before each one. Your other vendors will have their own cadences. Every release, field change or new picklist value is a potential break.

Agree a change process before go-live: who reviews vendor release notes, which integration tests re-run after each update, and who approves changes to mappings. Put a regular reconciliation in the calendar too. A quarterly check that headcount matches across HRIS, payroll and IAM catches the silent failures question eight warned you about.

The test that matters most

A good integration design document should be readable by both your IT lead and your HR Director. If only one of them understands it, you already have a governance problem.

The IT lead needs to see the endpoints, the error handling and the retry logic. The HR Director needs to see which employee journeys it supports, what data moves where, and what happens to a leaver's record. Both need to agree on who owns what. When the document only speaks one language, decisions get made by whoever happens to be in the room — and the other side finds out when something breaks.

So before you build, sit both of them down with these ten questions. If you can answer all of them, you're ready. If you can't, you've just saved yourself a very expensive few months. No bull.

Need a second pair of eyes on your integration design? Udder's consultants work hands-on across core HR, payroll, talent and learning platforms — from selection and design through to testing and adoption. Talk to the herd.

Sources

• MuleSoft, Agentic Transformation Reaches New Heights: 2026 Connectivity Benchmark Report Insights (February 2026)
• Gartner, 12 Actions Data and Analytics Leaders Can Take to Improve Data Quality (July 2024), via Verato
• Redfern Legal, ICO guidance on the processing of employment records by employers
• Trilateral Research, ICO draft guidance on employment records and recruitment
• ICO, What needs to be included in the contract? (controller–processor contracts, Article 28)
• ICO, Right of access: what should we consider when responding to a request? (updated December 2025)
• ICO, Right to erasure
• Microsoft, Retry pattern — Azure Architecture Center
• University of Maryland ERP Services, Workday Releases

This article is general guidance, not legal advice. Check data protection decisions with your DPO or legal team.