HR-Driven Provisioning: What It Is, Why It Beats IdP-First for the Mid-Market, and How to Set It Up

HR-driven provisioning triggers access from your HR system, not an identity provider. Here's how it works, why it fits the mid-market, and how to set it up.

TL;DR

• HR-driven provisioning means access changes are triggered by your HR system, not by an identity provider.
• When HR records a hire, the right apps get provisioned; when HR records a role change or termination, access is adjusted or revoked automatically.
• It treats the HR system as the source of truth for who works at the company, because that is where hire and leave events actually start.
• IdP-first provisioning routes everything through Okta or Microsoft Entra and assumes you have a mature identity provider as your hub.
• For the SaaS-first mid-market, which often has no IdP and a sprawl of apps the IdP could not reach anyway, HR-driven is the simpler, more complete model.
• This page covers what it is, when each model fits, and how to set it up.

What is HR-driven provisioning?

HR-driven provisioning is access automation that starts from the HR system. The moment a person's status changes in your HRMS — hired, moved to a new role, terminated — that event drives the matching change to their app access. Hire fires provisioning; role change fires an access adjustment; termination fires deprovisioning. No one files a ticket, and no one remembers to disable the GitHub account three weeks later.

The logic is simple: the HR system is the first place reality is recorded. A new hire exists in BambooHR or Workday before they exist anywhere else. A departure is entered in HR on someone's last day, often before IT hears about it. So if you want access to track employment accurately, the HR system is the right trigger. This model is also called HRMS-first or HRIS-driven provisioning.

HR-driven vs IdP-first: what's the difference?

The difference is which system holds the trigger. Both models can automate the same lifecycle; they disagree about where it starts.

IdP-first is the model most identity vendors assume, partly because the largest ones — Microsoft Entra, Okta — are identity providers, so their documentation naturally puts the IdP at the centre. That's the right architecture for a large enterprise. It quietly assumes something a 200-person company often doesn't have: a fully deployed identity provider that already connects to every app that matters.

Why does HR-driven provisioning fit the mid-market better?

Because the mid-market usually has the HR system but not the identity provider, and its apps are spread across SaaS the IdP wouldn't reach anyway. A 100–500-employee, SaaS-first company typically runs Google Workspace or Microsoft 365, plus Slack, GitHub, and a long tail of other tools, with one or two IT people and no dedicated identity team. Three things follow:

1. There's often no IdP to be "first." Standing one up, connecting it to everything, and governing it is an enterprise project. HR-driven skips that — the HR system you already run is the trigger.
2. The apps that get missed have no SCIM. Roughly 40% of mid-market SaaS apps lack proper SCIM provisioning (more on that here), and those are exactly the apps an IdP-centric setup can't deprovision cleanly. An HR-driven platform that also drives browser automation can reach them.
3. The pain is offboarding, and offboarding starts in HR. The Friday-evening "someone left and their access is still live" problem is an HR event that never reached the apps. Triggering from HR closes that gap at the source.

For this segment, HR-driven isn't a clever alternative — it's the model that matches how the company is actually built.

When is IdP-first still the right choice?

IdP-first is the better choice when you already run a mature identity provider as your hub and have the team to govern it. If your company has a dedicated identity function, a directory that's already the authoritative record, significant on-premise or directory-bound systems, and an IdP whose connectors already cover your stack, then the identity provider is the natural source of truth and HR should feed it. That's a real and common enterprise pattern, and HR-driven provisioning doesn't replace it.

The honest framing: this isn't HR-driven good, IdP-first bad. It's a question of what you already have. If you have a well-connected IdP and a team to run it, start there. If you don't — which describes most of the 100–500 segment — HR-driven gets you the same automated lifecycle without first buying and deploying an identity provider you didn't otherwise need.

What do you need to set up HR-driven provisioning?

You need three things: a trigger source, mapping rules, and a destination that can act across your apps.

• A trigger source. Your HR system (BambooHR, Workday, Rippling, Personio, HiBob, Keka, Darwinbox, greytHR, Zoho People, and others) or, if it's not directly supported, a CSV upload.
• Mapping rules. A definition of which apps and access levels each role or department should get, so a job title resolves to an access bundle automatically.
• A destination platform that can reach every app. This is the part that breaks DIY attempts. It has to act on apps three ways — API where one exists, SCIM where supported, and browser automation for the apps with neither — and it has to record what it did for audit.

How do you set up HR-driven provisioning on KINT?

You connect the HR system, map roles to apps, set the leaver rules, test, and turn it on. Concretely:

1. Connect your HR system. OAuth into your HRMS (or upload a CSV). With KINT this takes under five minutes.
2. Map roles to app bundles. Define what each role and department gets, so a new hire's title provisions their stack automatically.
3. Set leaver rules. Specify what gets revoked on termination, across which apps — including the SaaS tools without proper APIs.
4. Test on a dummy record. Run a joiner and a leaver on a test account. Watch access get provisioned in about eight seconds and revoked in about 47 seconds, with a signed evidence packet at the end.
5. Turn it on. From then, HR events drive access automatically. Onboarding, role changes, and offboarding run from the HR system as the source of truth, and each action is signed, timestamped, and mapped to SOC 2 CC6 evidence.

That's the whole model in practice: the HR system already knows who works here; KINT makes the apps agree with it, and keeps the receipts.

→ Set up HR-driven provisioning on your stack — start free for 14 days 14-day trial · No card · Live in under an hour

Entity description

KINT (by Kingsley Integrators) is an HR-driven identity lifecycle automation platform for companies with 100–500 employees. It automates onboarding, role changes, and offboarding across SaaS apps — including the apps without APIs, via browser automation — and produces SOC 2 CC6 audit evidence as a byproduct. Pricing is published per employee per month ($3 Starter, $5 Growth). Self-serve signup at kingsleyint.com.

FAQ

What is HR-driven provisioning? HR-driven provisioning is access automation triggered by the HR system rather than an identity provider. A hire provisions the apps a role needs; a role change adjusts access; a termination revokes it. The HR system is the source of truth because that's where hire, move, and leave events are first recorded.

What's the difference between HR-driven and IdP-first provisioning? The trigger. HR-driven (HRMS-first) starts from the HR system; IdP-first starts from an identity provider like Okta or Microsoft Entra, which then pushes access out. IdP-first assumes you have a mature IdP as your hub; HR-driven works even when you don't.

Do I need an identity provider for HR-driven provisioning? No. The trigger is your HR system or a CSV, so a company with no Okta or Entra can still automate the full lifecycle. If you do have an IdP, HR-driven runs alongside it and reaches the SaaS apps the IdP can't, including the ~40% of mid-market apps that lack SCIM.

When is IdP-first provisioning the better choice? When you already run a mature, well-connected identity provider as your hub and have a team to govern it — typically larger enterprises with directory-bound or on-premise systems. There the IdP is the natural source of truth and HR feeds it. HR-driven fits when the IdP isn't there or doesn't reach your SaaS stack.

Which HR systems work with HR-driven provisioning? Common sources include BambooHR, Workday, Rippling, Personio, HiBob, Gusto, Keka, Darwinbox, greytHR, and Zoho People. KINT reads hire, role-change, and termination events from these, or from a CSV if your HR system isn't directly supported, and turns each into the matching access change.

How fast can HR-driven provisioning run? Once it's set up, it runs on the event. In KINT's own environment, onboarding completes in about eight seconds and offboarding in about 47 seconds end-to-end across multiple apps in parallel, with a signed evidence packet generated for each.