Think You Don't Need a Data Layer for HR? Answer These First
Most leaders who say HR doesn't need its own data layer aren't wrong about their iPaaS. They just haven't been asked the questions that show what it doesn't cover.
So this is not an argument. It's five questions you can run on your own environment in an afternoon. If your team answers them fast and from one place, you probably don't need anything new. If the answers turn into a fire drill, you found your gap.
This is written for the HRIS or people systems leader who keeps hearing "we already have that handled" and wants a clean way to settle it. None of it is a knock on IT. Your integration team is usually answering a different question than the one HR has, and these questions surface the difference.
1. "Those feeds just run, they're fine."
Fair point. Most HR integrations were built once and have run for years without anyone touching them.
The question: Pull your last 30 days of integration activity. How long would it take your team to answer this, who got sent to which vendor last Tuesday, why, and what changed since the prior send?
A clean answer takes minutes and comes from one source. The common answer is a scramble across SFTP logs, vendor portals, and someone's memory, and even then it does not tell you what actually changed. A feed running tells you nothing about what it did, which is exactly what you need the moment a number looks wrong.
2. "We have a process when something breaks."
Also fair. Every team has a way to handle a bad file.
The question: When a vendor flags a missing or bad record, walk me through what your team actually does. Who pulls what, from which tool, in what order, and how long until you have the answer?
Listen for the number of tools and the number of people in that answer. A controlled setup resolves it from one place with a clear owner. The usual reality is a relay: HR opens a ticket, IT checks the middleware, someone exports from the HRIS, a benefits analyst runs VLOOKUPs against the vendor file, and by the time it reconciles, the data has moved on. You end up debugging week three in week seven. The process exists, it just costs days that show up on no budget.
3. "IT owns integrations. HR doesn't need its own thing."
This one is usually said with good reason. Integration is IT's discipline, and HR rarely staffs engineers.
The question: When a benefits plan year shifts or the business reorganizes, who changes the field logic, and is that a change HR makes directly or a ticket HR files and waits on?
This is the ownership test. The logic that decides what a field means, effective dating, cost center derivation, eligibility, changes when the business changes, and HR is the only function that knows the intent. When every one of those changes is a ticket, HR is accountable for an outcome it cannot control, and the timeline disappears into the queue behind IT's other priorities.
4. "We can just build that in our iPaaS."
You can build pieces of it, and a strong iPaaS team will. The real question is whether it holds up.
The question: If one field updates for one vendor feed, can you refire only that feed, or does the whole batch reprocess? Can you hold one bad record without stopping everything behind it?
These are not exotic requirements. They are ordinary HR situations: a single correction that should not trigger a full resend, one bad dependent record that should not block payroll for everyone else. General middleware tends to treat data as one size fits all, so the nuance gets dropped or hand-keyed back in.
5. "We're not under audit pressure, so this can wait."
Maybe. Plenty of teams have no formal audit requirement today.
The question: If an executive asked tomorrow to see exactly what you sent for one employee on one specific date, every field and every transformation, how many people and how many hours would it take to produce it?
You do not need a regulator to need that answer. A board question, a comp dispute, a termination that went wrong, any of them puts you in the same spot. If the honest answer is "a few people and most of a day," the risk is already sitting in your function, audit or not.
Add Up Your Answers
If your team handled all five cleanly, you are in good shape. Keep your iPaaS and move on.
If three or more turned into a fire drill, the problem sits one layer above your iPaaS, in how HR data gets defined and governed before anything moves. Tuning the middleware will not reach it. That is the case for a data layer HR actually owns.
The point of these questions is that you do not have to take our word for any of it. Run them on your own setup and let the answers decide.
The Honest Version
The objection is rarely wrong about the iPaaS. It answers the question IT has, which is how to move data between systems. HR carries a different question, who controls what that data means, and can we prove what we did with it. A data layer is the answer to the second one.
Run the five questions. Let the answers settle the debate.
