Connecting your ATS to an HRIS and payroll: when it's worth it and what a good integration looks like #

Before you start tackling an integration between your ATS and an HR information system (HRIS), realize one thing: in recruitment you record surprisingly few data points about a candidate that are actually useful in an HRIS — name, contact, which position they applied for, on what terms, and when they can start. And even those don't quite fit: a job title almost never equals the catalog position in an HRIS. So you have to weigh this small set of data against the cost and reliability of the integration. For a simple candidate handover, integration often isn't worth it; the real value shows up only in robust flows — where open positions are loaded from the HRIS into an offer, "locked," and the whole record is transferred into onboarding. A topic of its own is then the preboarding questionnaire and separating recruitment data from employee data (data protection).

How much recruitment data is actually useful in an HRIS? #

In the recruitment process you typically record first and last name, personal email and phone, which position the candidate applied for, the terms on which you offered them a start, and when they can start. That's all — and even that is only partly useful in an HRIS.

A good example is the job title. You won't find the posting "Looking for an HR buddy with a love for people" in the contract or the HRIS — there it'll be a catalog position like HR generalist. So the amount of data you'd be "retyping" into the HRIS is small, and part of it has to be mapped to different values anyway.

So frame it as a cost-benefit equation: how much manual work the integration saves versus what it costs and how reliably it will work when you need it.

When basic integration isn't worth it — and when it is #

In most real-world cases, it turns out that integrating the basic set of data isn't worth it. The exception is very open systems that offer a simple API integration — there it can make sense even for a few fields.

With large systems like SAP SuccessFactors, Taleo, or Workday, on the other hand, expect the integration to be non-trivial: every HRIS implementation is a little different at every company, so the connection is always something of a bespoke project.

Related features: HRIS integration · API · Webhooks

What a robust HRIS integration looks like (with an example) #

The real power of the connection shows when the integration doesn't start at handing over a finished candidate, but much earlier — at the offer, or even at the requisition. Let's illustrate it with a robust model like the one used, for example, with SAP SuccessFactors.

1. Requisition from a manager. The integration can begin with loading the position details entered by the manager from the HRIS.
2. Open "seats" (to be hired). When creating an offer, the positions open for hiring are loaded from the HRIS — and with a view into the future too. A typical case: someone is still sitting in the seat, but they're on notice or leaving for parental leave on a given date; meanwhile you already need to make an offer to a candidate who may have a notice period of their own. Being able to filter positions that open in, say, two months is essential here.
3. Parameters from position management. For each seat, attributes are loaded from the HRIS — location, grade, manager, employment type, number of openings, and often benefits too.
4. Pre-filling the offer on the ATS side. This data is pre-filled into the offer form in the ATS. You add the money and the start date, and the offer is generated in the company's design.
5. Locking the seat. On the HRIS side, the position is "locked" so it can't be offered to another candidate. Unlocking isn't missing either — when a candidate declines the offer, the manager doesn't approve it, or the candidate is rejected.
6. Transfer into onboarding. When the offer goes through, the seat and its data are transferred to the next phase. The candidate then doesn't have just a first and last name, but a whole record derived from the identifier of the specific position.

It's exactly these wrinkles (forward-looking positions, locking, unlocking, attribute mapping) that make an HRIS integration demanding — and at the same time it's only here that it delivers real value.

Related features: SAP SuccessFactors integration · HRIS integration

Preboarding and the employee questionnaire: when and where to send it from #

Connecting to an HRIS also raises the question of when to send the candidate an employee questionnaire — the form through which, in the preparatory (preboarding) phase, you collect data for the contractual documentation: the exact permanent address, ID card number, date of birth, and other data needed to register the employee and sign the contract.

Recommendation: if you don't use a dedicated preboarding/onboarding tool, send this questionnaire from the HRIS — so the form populates data directly in the HRIS and, via dynamic fields, creates the employee there for you. You can initiate the link to the questionnaire for the candidate from the ATS too ("here, fill in this set of details for me").

A key advantage of this separation is legal: recruitment data and employee data are typically held on different legal bases, with different retention and erasure obligations. In practice that means an employee often can't simply have all their data erased on request — statutory record-keeping duties (for example, retention for pension and social-security purposes for a legally set number of years) can override an erasure request. This is not legal advice — confirm the specifics with your own counsel.

Related features: Onboarding integration · Candidate data & privacy →

Complete list of questions for an ATS vendor →

← Back to the ATS selection guide