When HR teams evaluate onboarding automation, the conversation usually starts with features: what does the product do, how does the workflow work, what does the dashboard look like. The conversation that should happen first is about integration architecture: how does the system know when to fire, and how reliably does that signal arrive?
The integration layer is where most onboarding automation actually breaks down -- not in the workflow logic, but in the signal that starts it.
Event-based vs. polling-based integrations
HRIS and ATS systems fall into two broad categories from an integration standpoint: those that emit events you can act on in real time, and those that require you to poll for changes.
Event-based systems (webhook or event bus) notify your automation layer when something happens -- "offer accepted," "new hire record created," "employment status changed to active." Your system receives the event, processes it, and fires the workflow. Latency is typically seconds. This is the clean integration pattern.
Polling-based systems require your automation layer to periodically check the HRIS for changes -- query the API every 15 minutes, compare to last known state, identify what changed, act on changes. This introduces latency (up to the polling interval), requires more complex change-detection logic, and puts more load on both systems. It works, but it's messier and less reliable at high hire volumes.
Before committing to any onboarding automation platform, the first question to ask is: does my HRIS emit webhook events for hire status changes? If yes, you're in the clean path. If no, ask what the polling interval is and how the platform handles polling failures.
HRIS systems and their integration characteristics
The major HRIS platforms differ meaningfully in their integration capabilities:
- BambooHR: Supports webhooks for hire status events via their integrations module. The webhook payload includes hire ID, fields you've configured, and timestamp. Reliable event source for triggering onboarding workflows.
- Workday: Enterprise-tier, uses a combination of EIB (Enterprise Interface Builder) and custom integrations. Webhook-style events require configuration by your Workday admin. If you're on Workday, confirm your instance has outbound event notifications enabled before evaluating any automation vendor.
- Rippling: Developer-friendly; offers webhooks for most HR events including new hire creation. One of the easier platforms to integrate with for automation purposes.
- HiBob: REST API with webhook support. Events for employee lifecycle stages including new hire creation. Solid integration surface for mid-market companies.
ATS systems (Greenhouse, Lever, Ashby) generally have cleaner event architectures than HRIS systems, because ATSs are designed to hand off data to downstream systems at the offer stage. Most support webhooks for offer acceptance events with good field coverage.
The dual-system problem
Many companies use both an ATS and an HRIS, and a hire's journey crosses both: the ATS manages the recruiting process through offer acceptance; the HRIS takes over once the hire is official. This creates an integration decision: do you trigger onboarding automation from the ATS event (offer accepted) or the HRIS event (hire record created)?
The answer depends on your process:
- If there's always a same-day sync from ATS to HRIS when an offer is accepted, either trigger works -- the HRIS event is slightly safer because it means the hire record exists and can be referenced.
- If the ATS-to-HRIS sync is manual or batched (some companies do this weekly), the ATS offer-acceptance event is the better trigger -- waiting for HRIS sync means the workflow fires late.
- For I-9 specifically: you need a new-hire record with an employment start date to properly set the I-9 completion deadline. This argues for triggering I-9 from the HRIS record, not the ATS offer event.
Handling integration failures gracefully
Even clean webhook-based integrations fail sometimes: the HRIS vendor has downtime, the webhook endpoint is unreachable, a payload is malformed. The question is not whether failures will happen but whether your automation layer notices and recovers.
Minimum-viable failure handling for an onboarding automation integration:
- Idempotent event processing: If the same hire event fires twice (HRIS retry on failed delivery), the workflow should not start twice. Each workflow execution should check for an existing run for that hire ID.
- Failed event queue: Events that can't be processed should go to a visible queue, not fail silently. An HR coordinator should be able to see "3 events failed to process this week" and investigate.
- Start-date safety check: Regardless of when the workflow starts, a pre-Day-1 status check should verify that all tracks have completed signals. This catches the case where the event fired but something downstream didn't complete.
When evaluating an onboarding automation vendor, ask specifically how they handle integration failures. The answer is revealing. Vendors with mature integration layers have specific answers; vendors where integration is an afterthought will describe a workflow engine without explaining what happens when the signal doesn't arrive.