Most explanations of HRMS integration stop at "it connects your HR system to IT." That's the easy part. The harder, more useful question is what happens after the connection exists: how fast a change actually propagates, what happens when someone's role changes mid-cycle instead of a clean joiner or leaver event, and whether onboarding and offboarding really run through the same logic or two different ones wearing the same label. (For the broader case behind this approach, see our guide to HR-driven provisioning as a concept.)
An HRMS integration sounds like a single thing: connect the HR system, done. In practice it's two distinct flows sharing one connection, onboarding and offboarding, plus a third case most explanations skip entirely: what happens when a record changes in between.
This piece covers all three. Not the attribute-level condition logic that decides what gets provisioned, that's covered in how Zluri handles HR-driven provisioning. This is about the connection itself: how the sync behaves, and what actually happens on both sides of it.
What the Integration Actually Connects
Zluri connects directly to the HRMS platforms companies already run, BambooHR, HiBob, PersonioHR, ADP Workers, Rippling, Namely, Keka, and others, reading employee records as they're created and updated rather than waiting for a second, manual notification.
That connection serves two distinct purposes at once:
- A trigger. A new hire record, a status change, a termination date, each becomes an event Zluri can act on directly.
- A data source. The same connection supplies the attributes, department, designation, employment type, that determine what gets provisioned, not just when.
Losing sight of the second purpose is a common mistake. A fast trigger connected to stale or incomplete data still produces the wrong outcome, just faster than before.
How the Sync Actually Works
Real-time sync isn't universal across every HRMS, and it's worth being specific about what actually happens rather than assuming instant is instant everywhere.
Where an HRMS supports webhooks, Zluri receives the event as it happens, typically within minutes. Where it doesn't, Zluri polls on a scheduled interval instead, close to real time but not instant. Either way, the moment that matters is when the HR record itself changes, not when someone gets around to mentioning it.
The distinction that actually matters isn't webhook versus polling. It's that both paths read the HRIS record directly, with no manual relay step in between.
The Onboarding Flow, End to End
- HR creates the new hire's record in the connected HRMS, with a start date
- Zluri detects the record on the next sync cycle, or immediately where webhooks are supported
- The employee's attributes, department, designation, location, employment type, get evaluated against policy
- The matching onboarding playbook fires, provisioning the apps and access that policy calls for
- Access is live before the person's actual start date, not scrambled together on it
The Offboarding Flow, End to End
- HR marks the employee's status as terminated, or a termination date is reached
- Zluri detects the change on the same sync path as onboarding, no separate mechanism to configure
- The offboarding playbook fires, revoking access across every connected application, not just the identity provider
- The action is logged with a timestamp tied to the HRIS record itself, not to whenever IT happened to act
Offboarding runs through the identical trigger mechanism as onboarding. That symmetry is intentional: a company that automates joining well but leaves leaving manual has only solved half the problem, and usually the less risky half.
What Happens When a Record Changes Mid-Cycle
Not every HR event is a clean joiner or leaver. A role change, a department transfer, a promotion, these fall in between, and they're where most manual processes quietly break down.
The mechanism is the same sync path described above. What changes is the outcome: instead of a single onboarding or offboarding playbook, a role change evaluates the person's new attributes against policy and applies both halves of the update.
- New access gets granted for the new role
- Old access tied specifically to the previous role gets revoked
The second half is the one manual processes skip. Movers are commonly the identity-management case that gets forgotten, precisely because granting new access reads as a completed task the moment it's done, while removing the old access was never anyone's assigned step.
Where This Fits Relative to Zero-Touch Provisioning
This integration is the trigger layer. It answers when something changed and supplies the context needed to act on it correctly. What happens downstream of that trigger, the account creation, the permission configuration, the verification that access actually works, is the broader scope covered in zero-touch provisioning. HRMS integration is the prerequisite piece; zero-touch is what it makes possible.
Frequently Asked Questions
Does this integration handle both onboarding and offboarding, or just one?
Both, through the same connection and the same underlying sync mechanism. Offboarding isn't a separate integration bolted on afterward; it reads from the same HRMS event stream that drives onboarding.
How fast does a change in the HRMS actually reach Zluri?
It depends on what the specific HRMS supports. Where webhooks are available, changes are received as they happen, typically within minutes. Where they aren't, Zluri polls on a scheduled interval instead, still close to real time, but not instant.
What happens if someone's role changes instead of them joining or leaving?
The same sync path detects the change and evaluates it against policy, but the outcome has two parts: new access for the new role gets granted, and old access tied to the previous role gets revoked. The revoke half is the one most manual processes miss.
Does this integration decide what specific apps get provisioned?
It supplies the trigger and the attributes, department, designation, employment type, that policy evaluates. The condition logic that turns those attributes into specific provisioned apps is covered separately in how Zluri handles HR-driven provisioning.
Which HRMS platforms does this connect to?
Pre-built connections are available for BambooHR, HiBob, PersonioHR, ADP Workers, Rippling, Namely, Keka, and other common HR systems, with the sync behavior, webhook-based or scheduled polling, depending on what the specific platform supports.
.svg)
