How do I connect our ATS to payroll and onboarding?

Transfer a defined set of information at a defined moment, reliably, without creating duplicates. The moment is normally offer acceptance or start date confirmation. The information is typically name, contact details, role, department, manager, location, start date, employment type and compensation, though compensation often has separate permission rules. The receiving system then owns the employee record and triggers onboarding tasks, equipment requests and payroll setup. Decide the direction of flow explicitly: hiring data usually pushes forward into the HRIS, while some organisations also pull department, cost centre or approved headcount back into the recruiting system so requisitions reference real structure. Write this down as a short specification before evaluating connectors, because vendors describe integration capability in general terms and your requirement is specific.

Three, in descending order of convenience. A native connector built by one of the vendors for the other, which is the least work and the most reliable, though the field mapping may be fixed. An integration platform sitting between the systems, which handles many combinations and gives you control over mapping and transformation at the cost of another subscription and another dependency. A custom build against both APIs, which gives complete control and puts maintenance permanently on your team. Most organisations should exhaust the first option before considering the others. During evaluation, ask not whether an integration exists but which of these three it is, who supports it when it breaks, and what happens when either vendor changes their API. Verify it against your specific integration requirements rather than a logo on a partner page.

Field mapping mismatches, where the two systems structure the same concept differently: employment types, location hierarchies, department codes and job titles rarely align without translation. Duplicate handling, particularly for rehires and internal moves, where a person exists in both systems already. Timing, where onboarding needs to start before the payroll record can be created, or where the start date shifts after transfer. Permissions, where compensation data should reach payroll but not general HR users. And error handling: what happens when a transfer fails, who is notified, and how it is retried. Ask about that last one specifically, because silent failures are common and are usually discovered when someone does not appear in the payroll run.

Test with real records in a non-production environment if one is available, covering the ordinary case and at least four edge cases: a rehire, an internal transfer, a start date change after transfer, and a failed transfer. Then run the first few real hires with a manual verification step, where someone confirms the employee record before onboarding proceeds. Keep that check until you have seen it work through a full cycle including a payroll run. Document who owns the integration, how errors are reported and who to contact at each vendor. Finally, agree what happens during upgrades: both vendors will change their systems, and an integration with no named owner degrades quietly until someone notices a missing record.