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).

Department, and the other four, are sets — not single values

department · function · cost_center · location · company can each hold more than one value at once for the same identity. A person doing rotational work across IT and Finance is genuinely in both — not "primarily" one with the other as metadata, and not a value that has to be resolved down to a single answer before anything else can use it.

This matters everywhere a policy or a mover trigger reads one of these attributes, because the natural first assumption — "department is a field, so I'm asking what one thing it equals" — is too narrow. The real question is always "is X among this identity's values," and every access-grant policy, dynamic group and mover check is evaluated that way.

Worked example. Priya works a rotation split between IT and Finance, so her department membership set is {IT, Finance}. The tenant has two department-scoped access grant policies:

Policy	Scoped to	Grants
IT Baseline Access	department includes IT	VPN group, IT ticketing tool
Finance Reporting Access	department includes Finance	Finance reporting dashboard, expense system

Both policies match Priya — not just the one that happens to be stored as "primary" — so she holds the full union of both grant sets. If she rotates off Finance next quarter, her membership set drops to {IT}, the Finance policy stops matching, and reconciliation converges her access down to IT Baseline alone.

The same set drives mover detection when the change arrives through the attribute-mapped HR sync: joining a department, leaving one, not just swapping a single value, fires the mover trigger described above, so the access recompute sees the identity's real, current membership rather than whichever single value was written last. A change that instead arrives as a context-assignment membership edit — a secondary department added or removed while the synced primary value stays the same — does not fire that same-run trigger; it is picked up on the next scheduled reconciliation pass rather than immediately.

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) — Expected access falls away, reconciliation revokes the assignments and disables the accounts, and optional GDPR pseudonymisation follows after the retention window. An overdue leaver surfaces as a leaver_overdue exception with an escalate-or-force path.

Not everything called "terminated" is the same thing

How fast access falls away depends on how the identity became terminated, and the distinction is deliberate:

• An emergency lockout (status SUSPENDED) empties Expected access at once. No grace, no configuration to soften it. This is the security override, and it is reversible: lift it and the full picture is recalculated on the next run.
• An explicit decommission — somebody deliberately retired this identity — also empties it at once. That call already revoked every assignment when it was made, so allowing a grace window to hand access back afterwards would quietly undo a decision a human took.
• A passive leaver — an end date passed, or HR flipped the status — is grace-aware. Access is calculated exactly as it would be for an active person, and each entitlement is then judged individually: anything privileged is dropped immediately when the tenant has asked for that, and everything else survives until the grace window measured from the termination runs out.

The default grace is zero, so nothing changes for a tenant that has not asked for it. The reason the window exists at all is that "revoke everything the instant HR says so" and "leave it until somebody remembers" are both wrong, and only the organisation can say where between them it sits — a departing employee may legitimately need the shared mailbox for a fortnight, and never needs the production admin account for another minute.

After the disable: delete, and when

Disabling is not the end of the story, because a disabled account left indefinitely is still an account. A separate sweep finalises leaver accounts once a configurable number of days have passed since they were disabled — again scoped strictly to genuinely terminated identities, never to a lockout, so lifting a suspension never finds the account gone.

What finalising means depends on what the target can actually do. Where the connector has a real delete primitive the account is deleted in the target; where it does not, the account is marked for deletion rather than pretended about. Active Directory can additionally move a leaver's account to a designated organisational unit before disabling it, per account type, which is how most organisations want their leavers parked while the grace period runs.

⚠ 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.

When something else already owns the write

If an upstream sync of your own is in play — on-premises Active Directory feeding Entra Connect, say — then certain JML actions are blocked on the target systems that sync manages. A joiner workflow with "create the AD account" as a step has to work through the source; attempting it against the target raises a task for a human instead of racing the other tool. See imports and schedules for how that ownership is declared.

---

Further reading:

• Reconciliation
• Cert Flows
• Imports and schedules
• Approver Chains