Joiner / Mover / Leaver Flows

Joiner, mover and leaver events — triggers, workflows, and leaver safety.

What is a JML event?

Joiner / mover / leaver (JML) are the three lifecycle events that identities go through. JML events are detected from changes in HR syncs (a new row is a joiner, a changed department or manager is a mover, an end date in the past is a leaver) and published on the event bus for downstream workflows.

JML owns no access — the model (revised 2026-06-19)

JML does not own access and is not a second provisioning path. Access is always driven by access grant policies plus reconciliation: birthright is simply a policy match (provenance policy), and reconciliation converges the target to the Expected state. JML itself is two things:

Global settings — one JmlSettings record per tenant: validity-window fallbacks (before/after start and end date), leaver grace and privileged-immediate behaviour, mover retention and attestation defaults, rejoiner review, and SLA thresholds. Per-population validity windows live on the access grant policy, not in JML.
Monitoring — surfacing lifecycle exceptions, for example leaver_overdue (access is still present that should be gone → escalate or force) and retained_critical (privileged access that is Expected but deserves tightening).

Grant provenance uses a fixed vocabulary: policy · request · manual · sync. The reconciliation comparison is labelled Expected / Actual throughout the product.

Joiner — what triggers it

The HR sync detects a new Identity row.
A JMLEvent row is written with event_type=joiner plus identity context.
Workflow definitions with trigger_event_type=joiner are executed (per tenant). Common ones: notifications, generated values, welcome email.
Birthright access comes from access grant policy matches (including bare-account grants, e.g. "every employee gets an Active Directory account"); recomputing the Expected access and reconciling (Expected vs Actual) drives auto-provisioning — there is no separate JML provisioning path.

Mover — the most complex

Mover events fire when one of the identity's trigger attributes changes (configurable via IdentitySyncConfig.sol_trigger_attributes). The default set is department, function, manager_id, cost_center, and location.

Expected-access recompute: what access belongs to the new role?
Diff old versus new Expected: which assignments become obsolete?
Mover treatment is per provenance: context-bound explicit grants → attest (a mover access-review fan-out over exactly those assignments), old-policy grants → auto-revoke, role-based assignments → retain.
The mover access review is the event-driven review rule cr-mover-grants-event (on by default) — there is no separate access-review path.
Mover configuration cascades: per-context override → per-dimension default → hard fallback (grace and attestation deadline per context).

Leaver — soft versus hard

Leaver events are detected via identity.end_date < now or an explicit status change to TERMINATED.

Soft leaver (end date in the future) — no action, just an indication in the UI.
Hard leaver (end date passed or status TERMINATED) — the Expected access becomes empty (the calculator short-circuits on status SUSPENDED/TERMINATED): reconciliation revokes all assignments and disables accounts. Optional GDPR pseudonymization follows after the retention window. JmlSettings governs grace days and privileged-immediate behaviour; an overdue leaver surfaces as a leaver_overdue exception with an escalate/force path.

⚠ Note

A hard leaver triggers a revoke on every target system where the identity has an account. ALWAYS test your leaver flow with a dummy account in a development environment — a misconfiguration here breaks legitimate users.

Relationship with Sync Strategy

If you have configured an upstream sync (for example on-premises Active Directory → Entra Connect), certain JML actions are blocked on target systems that are managed by that sync. A joiner workflow that has "create AD account" as a step must work through the source system; the platform spawns a ManualProvisioningTask if the admin tries to do it through the target.

Further reading: