Skip to content
SOLUTION · LIFECYCLE

JML — without the manual checklist.

Joiner, mover, and leaver events from your HR system or IdP become governed workflows across 200+ apps. Median offboarding: 47 seconds. Median onboarding: 8 seconds.

Solution path

Joiner, Mover, Leaver Automation

Positioning page, same KINT runtime. Source events, governed workflows, evidence, and replay stay in one operating model.

PROOF PATH

How the JML loop runs.

01

Authoritative event arrives from HRMS, IdP, CSV, or API

Authoritative event arrives from HRMS, IdP, CSV, or API

02

KINT reads role, manager, location, and lifecycle state

KINT reads role, manager, location, and lifecycle state

03

API, SCIM, and browser-only apps update in one governed workflow

API, SCIM, and browser-only apps update in one governed workflow

04

Every action lands in a signed SOC 2 / ISO 27001 evidence packet

Every action lands in a signed SOC 2 / ISO 27001 evidence packet

WHAT IT HANDLES

What JML automation looks like

Trigger sources: HRMS, IdP, CSV upload, API webhook, manual approval

Provisioning logic: role-based, location-based, manager-based, custom-attribute-based

Apps in scope: 200+ via API/SCIM, hundreds more via browser automation, all with evidence

Output: signed audit packet per workflow run, ready for SOC 2 / ISO 27001 evidence

WHY IT MATTERS

What JML actually is

Every IT team manages three lifecycle events.

A new hire joins and needs accounts created in twelve apps. An existing employee moves teams and needs old access removed and new access added. An employee leaves and every account, group, and license must be revoked across every app — including the ones nobody remembers.

Most teams handle this with a Notion checklist, a Slack ping to the IT inbox, and hope. At 50 employees this works. At 150 it cracks. At 300 it's broken.

KINT runs the JML loop end-to-end. Your trigger can be your HRMS, your IdP, a CSV, or an API call. KINT doesn't care where the event comes from — as long as it's authoritative. From there, governed workflows handle the rest.

When JML breaks

Onboarding gap

New hire shows up Monday without GitHub access. Manager pings IT. IT pings team lead. Team lead pings onboarding buddy. Two hours lost.

Mover gap

Someone moves from Eng to Sales but keeps GitHub admin. Three months later, an audit asks why a Sales AE has push access to production code.

Offboarding gap

Someone leaves Friday at 5pm. Their GitHub access expires 14 days later. By then they've cloned the repo.

FAQ

What's the minimum setup?

One source (HRMS, IdP, or CSV) and one target app. From there, add connectors as you trust the workflow.

Do we need Okta or Entra first?

No. KINT runs direct from HRMS to apps. If you already have an IdP, KINT works alongside it — closing the 40% of apps your IdP can't see.

What if our HRMS isn't supported?

Check /connectors for the current list. If yours isn't there, request it. In the meantime, CSV upload works.

Can workflows require human approval?

Yes. Any workflow can require approval before execution. Common patterns: admin-scope grants always require approval; offboarding for executives requires legal review; cross-region transfers require InfoSec review.

What happens to data the leaver owned?

Configurable per app. Slack DMs follow your retention policy. GitHub repos transfer by ownership rules. Google Drive files can move to the manager. You set the rules once.

How long until the first workflow runs?

From signup to first successful test offboarding: typically 25 minutes if you have HRMS API credentials ready.

Run the JML loop on your stack.