How to Connect ATS to Onboarding Without Re-Keying New-Hire Data

An ATS-to-onboarding handoff should create or update the new-hire record after an approved offer is accepted, using validated fields already held in recruiting.

Teams comparing recruiting software can use this overview to assess which workflow fits their hiring process. The integration should transfer only needed data, prevent duplicate employees, record success or failure, and assign unresolved exceptions to a named owner.

Move a small, trusted employment dataset once, then let the new hire complete or verify information in the onboarding system.

Key takeaways

• Use accepted and internally approved offer status as the transfer trigger, not a recruiter's informal stage change.
• Map fields by meaning, format, owner, and source of truth before configuring the integration.
• Transfer only onboarding data; leave rejected notes and unrelated recruiting material in the ATS.
• Match existing workers and rehires before creating a new employee record.
• Make failures visible and retryable without creating duplicates.
• Test new hires, rehires, internal transfers, changed start dates, rescinded offers, and missing fields.

What is an ATS-to-onboarding handoff?

An ATS-to-onboarding handoff transfers an accepted candidate into the system managing preboarding tasks, forms, policies, accounts, equipment, payroll setup, and employee records. This may be an HRIS, onboarding platform, payroll product, or workflow tool.

Manual copying creates typing errors, inconsistent formats, delays, and uncertainty over which version is correct.

When should the ATS send a new hire to onboarding?

The safest trigger is an accepted offer with all internal approvals. Some employers also require a completed condition before creating the employee. Define the event precisely rather than relying on a generic Hired stage.

A clear sequence is:

1. Compensation and offer terms receive internal approval.
2. The candidate signs or formally accepts the offer.
3. Required pre-transfer conditions are confirmed.
4. The ATS validates mandatory fields.
5. The integration checks for an existing employee or pending hire.
6. The receiving system creates or updates the record.
7. Both systems record the external ID, timestamp, and result.
8. Onboarding tasks begin and owners receive confirmation.

Avoid sending draft or verbal offers. Repeated edits before acceptance can create several incomplete employee records.

Which new-hire fields should transfer from the ATS?

Transfer fields needed to establish employment and begin onboarding. The exact set depends on country, worker type, HRIS, payroll, and policy.

Home address, bank details, tax forms, emergency contacts, benefits elections, and identity documents are often better collected and verified in a secure onboarding or payroll flow.

What should not transfer into the employee record?

Do not move the complete recruiting history by default. Interview notes, scorecards, rejected alternatives, recruiter comments, source messages, background reports, diversity monitoring data, and AI scores may be irrelevant to employment and visible to the wrong users after transfer.

Create a field-level rule: transfer, link, retain, anonymize, or delete. Legal, privacy, HR, and security owners should approve it by jurisdiction and record type.

How do you map ATS and onboarding fields?

For each mapped value, record its definition, type, format, required status, transformation, source, system of record after hire, and error owner.

For example, ATS value London may map to HRIS code GB-LON-01. A manager name may require an employee ID, full-time may map to REG_FT, and salary needs currency and pay frequency.

Keep a version-controlled mapping sheet with:

• ATS field and sample value
• Receiving field and allowed value
• Required or optional status
• Transformation and validation rule
• Sensitive-data classification
• Create, update, or no-overwrite behavior
• Business owner and technical owner
• Failure message shown to users

Do not silently truncate text or replace unknown codes with a default. Stop the transfer and ask the owner to correct the source record.

How do you prevent duplicate employee records?

Check for existing records using an employee ID, prior worker ID, verified personal email, or another approved identifier. Names change and are not unique.

Define separate behavior for:

• A brand-new employee
• A former employee returning as a rehire
• A current employee moving internally
• A contractor converting to employee
• One candidate accepting two assignments
• A duplicate application for the same person

Use an idempotency key based on the offer event or candidate and requisition IDs. A retry should return the existing result rather than create another person.

What happens when the integration fails?

A failed handoff must create a visible, actionable exception. “Sync failed” is not enough. Show the candidate, event, failed field, reason, last attempt, owner, and safe retry action.

Build three outcomes:

• Success: store the receiving-system ID and notify the onboarding owner.
• Retryable failure: queue another attempt after a temporary outage without duplicating the record.
• Data failure: stop, assign correction, and retry only after validation passes.

Reconcile accepted offers with onboarding records and report missing IDs, duplicates, changed dates, and canceled hires.

How should changes and rescinded offers sync?

Decide which system owns changes to start date, manager, location, title, or compensation. Do not allow conflicting two-way overwrites.

For a rescinded or declined accepted offer, send a controlled cancellation event that stops onboarding tasks and account creation. Preserve records required for audit or legal purposes, restrict access, and apply the correct retention policy rather than simply deleting all history.

Which integration method should you use?

Use a native connection when its fields, timing, monitoring, and support fit. Integration platforms connect systems quickly; APIs and webhooks allow more control; scheduled files suit stable batches. Require authentication, encryption, least privilege, logs, monitoring, and support. See connecting an ATS with HRIS, payroll, and onboarding for architecture choices.

How do you test an ATS onboarding integration?

Test in a nonproduction environment with synthetic candidate data. Cover ordinary cases and uncomfortable exceptions:

1. New employee with all required fields
2. Missing manager or invalid location code
3. Rehire matched to a prior employee
4. Internal applicant already active in the HRIS
5. Changed start date or compensation after creation
6. Rescinded offer after tasks start
7. Timeout followed by a safe retry
8. Deletion or retention request across both systems

Ask HR to verify the employee record and tasks. Technical success can still produce a wrong manager, currency, entity, or date.

How can Recooty support the handoff?

Recooty centralizes the accepted candidate's job, offer status, communication, evaluation, and hiring record. Its integrations and API options can connect recruiting with downstream HR and onboarding tools, reducing manual entry when the receiving workflow is configured correctly.

Treat Recooty as the source for approved recruiting fields and the HRIS as the source for employee data after transfer. Confirm field coverage, supported triggers, plan access, and exception handling for the specific integration before launch.

Frequently asked questions