Joiner / Mover / Leaver Flows

Joiner, mover and leaver events: employment rows, the identity's lifecycle window, the six statuses, staging before the start, and leaver safety.

What is a JML event?

Joiner / mover / leaver (JML) are the lifecycle events an identity goes through. They are derived from what HR delivers: a person's lifecycle window opening is a joiner, a change of department, function, location or manager is a mover, and the window closing (or HR saying the person is terminated) is a leaver. Each event is published on the event bus for downstream workflows.

JML owns no access

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. It holds the pre-validity default, the post-validity defaults (a general one, plus after leaving, after a move and after a context ends), whether privileged access drops immediately for a leaver, mover attestation, rejoiner review, what is prepared before activation, the derivation rule for a person's status, and SLA thresholds. A policy can override the pre- and post-validity days for its own grants.
• Monitoring: surfacing lifecycle exceptions, for example leaver_overdue (access is still present that should be gone → escalate or force), retained_critical (privileged access that is Expected but deserves tightening) and "Move not processed" (a move no reconciliation has covered yet; its button opens the person). A joiner, mover or rejoiner event, also one that failed, closes once a later reconciliation has covered the person, however many runs came after.

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

Pre- and post-validity: one rule for every lifecycle step

Every derived grant has a window that comes from its source: the context it was matched through, the moment a policy started matching, or a request's own dates.

• Pre-validity lets a grant start a number of days early, but only when the start is known in advance: a future-dated employment or membership, or a request with a future start.
• Post-validity keeps a grant a number of days after its source stopped granting it, but only for a natural lapse: a context ended, or a policy stopped matching. It never extends a deliberate revocation (a review, an admin, SoD), a lock, a dismissal for cause, a death or a no-show.
• An explicit end date is never extended. A time-boxed request, a JIT elevation and a break-glass activation end when agreed.

The leaver grace and the mover retention are this same rule: they are the after leaving and after a move defaults on the Lifecycle workbench's Post-validity card. The setup journey's Decide phase proposes the leaver grace from your own history: for the leavers of the last year it measures the days from the end date to the moment their first account was disabled, and proposes the median, with the number of leavers, the middle half, the range and the outliers beside it. Every leaver left out is counted under a named reason (no end date, no account, not yet disabled, and so on). Under ten measured leavers it proposes nothing and says how many are missing. "Use this" saves the value as shown or adjusted. The setting counts from the moment a person became terminated, the evidence from the end date: the two are the same day when HR marks leavers on their end date.

Employments: one person, several relationships

A person can have more than one relationship with the organisation at once: a main contract plus a secondment, a contractor who is also a board member, an alumna who is rehired. Each one is its own employment row with a start, an end, a status and a relationship type (employment, contractor, alumni and so on). The context memberships that one source record produced (company, department, function) belong to that row and share its window.

• Policies are evaluated per row. Every context condition of a policy must hold on the same row. A department from one employment and a legal entity from another do not combine to satisfy a policy that asks for both. A context that sits outside any row applies to every row.
• The union stays the union. Someone matching a policy through two rows holds the grant once. When one row ends, the grant is re-attributed to the row that still matches instead of being revoked.
• HR can deliver the rows. An employment object in the HR feed becomes employment rows. Rows are keyed on the record's own id, or on a generated key from source, person, legal entity, relationship type, start day and contract. If the key is ambiguous the record is not grouped and a finding is raised. A changed department on the same key is a move. An import never ends rows on an incomplete read and is subject to the same circuit breakers as the context import.
• A feed with only person dates still gets a row. When HR sends a start and end date per person but no employment object, each person gets one permanent row that carries their org contexts.
• A later end date is applied to an existing membership; it no longer needs a manual edit.

Employment rows are written through one service, and every change is audited and followed by a reconciliation run.

The main employment and the person's own fields

For a person with employment rows, one row is the main employment: the row an administrator pinned, else the row HR flags as main, else the highest FTE, else the longest-running, among the rows in force (or, when none is, the ones yet to start). A leaver keeps the row that ended last.

The person's five org fields (company, department, function, cost centre, location) and their manager are derived from the main employment. Older writers (the identity sync, an admin edit, the org-chart correction, the ingest API) leave those fields alone for such a person. To set a manager for the whole person, an administrator sets the identity-level manager, which wins over the main employment's manager. A person without rows keeps the old single-value fields.

Which manager decides

A manager's team is everyone they manage through any route: as identity-level manager, as the manager of an employment or relationship row that is in force or about to start, or as the project lead of a membership. The roster shows a person once per manager, with the route.

Approval and review steps that ask for "the manager" resolve in this order: the identity-level manager, then the manager of the context the access belongs to (the row or membership the grant is derived through, or the request item's bound context), then the main employment's manager. A step can ask for one of those sources specifically, and for one, all or any of the managers it finds. A project lead decides only what belongs to their project.

The Contexts over time card on an identity's Profile tab shows the rows and dated memberships as a timeline, with the manager of each, the gaps between them, and per link which entitlements start and end with it, including what pre- and post-validity add.

The lifecycle window

Each identity has a lifecycle window: when it starts being valid and when it stops. How it is derived is set per HR source:

• (a) Person dates: the start and end date HR delivers for the person.
• (b) Rows (the default): from the earliest start to the latest end of the person's employment and relationship rows. One open-ended row means no end. A department or location membership never counts.
• (c) Open: no end.

Before the window opens the person is pending; once it has closed they are terminated. A boundary sweep picks the edges up on the next reconciliation run.

Short gaps are continuity. When the tenant has a leaver grace, rows that start within that grace after the previous row ended are one stretch, so a contract renewal recorded a few days late is not a leaver followed by a rejoiner. The end of the last row is held for the grace for the same reason. A gap that is known to be longer makes the person a leaver from the end, and a rejoiner when the next row starts. With no leaver grace configured (the default), gaps are not read and the window is the whole span.

A feed's disabled flag is not a termination by itself. A REST, SQL or file feed that maps no status no longer terminates a person with a window because one record arrived disabled. A status comes from a source that supplies one: an HR feed that maps a status field, or a directory's own flag (SCIM, Google, LDAP and Active Directory). Otherwise the tenant's derivation rule decides from the relationships in force: by default an employment in force makes a person active.

A non-human identity has a window too, derived from its own dates and its owners' sponsorship under a declared lifecycle driver. A purpose-driven agent ends when its sponsor leaves; a service account does not.

The six statuses

An identity's status says how access behaves, not why. The reason (leave, pending hire, onboarding gate, security lock, window ended, or an HR reason) is kept beside it as a label.

Status	What happens to access
Pending	Not active yet: nothing is granted. Accounts can be prepared disabled before the start (see below).
Active	Everything the sources grant. A person on leave is active unless the tenant mapped that leave otherwise.
Active – no new access	What is already granted stays and is restored if it goes missing. Requests for the person, JIT elevations and break-glass activations are refused, and new policy matches are held ("held by status") until the status ends.
Restricted	Only what a named access profile lists stays, such as "mail only". An account with nothing left is disabled.
Locked	Accounts are disabled.
Terminated	The sources end, with post-validity per cause. Accounts are disabled and later deleted.

A status never withdraws a source. Restricted, locked and "no new access" only keep grants out of the Expected access. When the status ends, the Expected access is recalculated from the same sources, so requested and manual grants come back too, minus anything explicitly revoked or expired in the meantime.

Statuses apply per link, not only per person. An employment row, a membership and a context can each carry a status. Leave on contract A restricts only what is derived through A; contract B is untouched. A grant is as active as its most permissive reason, so a grant that both contracts derive stays. An account whose every reason is held by a status is disabled without starting the lapse clock and comes back when the status ends. An ended row or membership is different: it is no longer a source, so its grants lapse after post-validity.

The entitlement and its type are levels too. An entitlement that is not yet approved or created, or that is being deprecated, gives no new grant: what is already granted stays. A retired entitlement, or one an administrator has locked (on the entitlement itself or on its whole type, with a reason, on the entitlement's Status card), is held: the sources and the grant row stay, the permission is removed from the target and comes back when the lock is lifted. Requests, JIT elevations and break-glass activations refuse an entitlement that gives no new grant, and a new policy match on one is held and shown as such.

The older status names are gone. suspended, on_leave, pending_hire and gated are no longer statuses; they survive only as reason labels. A saved rule or view that still names one of them matches nobody, and a hand change of status offers only active and terminated.

Locked can have several sources. A security lock and an HR-mapped lock can hold at the same time; lifting one keeps the identity locked. A restricted person loses their RapidValue sign-in and approver roles; a person under "no new access" keeps them.

Where a status comes from

• The HR status mapping says, per HR source, what each HR value means: a status, a profile for restricted, an optional delay ("after 30 days") and a reason label. A value can sit on the person, on one employment row, on a context or on a relationship type. The mapping is off until the tenant adds a row for a source; a source without one is read as before. An unmapped value changes nothing and raises the finding hr_status_unmapped. Before the first row, the source lists every status value it sends, each with a proposed behaviour read from the data: the end dates of the people who carry it, whether their accounts in the target systems are still on, and the value's own words. The administrator sees who would change status and saves the chosen rows together; nothing applies before that. Go-live readiness lists an HR source that sends status values without a mapping row.
• The leave process is for tenants without HR leave data. The person's manager, HR or an administrator asks for a leave of one kind, for the person or one contract, for a period. HR approves it through the normal approval flow, and the requester never approves their own. The leave's mapped status is written when the period starts and lifted when it ends. Over a status somebody else set (an HR mapping or a hand-set restriction), the strictest wins: a stricter leave applies at once and, when it ends, the status it replaced comes back; an equal or milder leave waits as held until that other status ends. Every step is audited.
• The lifecycle window gives pending and terminated.
• The onboarding gate gives pending until the case is activated.
• A security lock gives locked until it is lifted.

The Advisor raises a hint when a person has a restricted or locked relationship beside another context that a policy still matches through. It informs; it changes nothing.

Joiner

• The HR sync creates the identity and a JMLEvent with event_type=joiner is written.
• Workflow definitions with trigger_event_type=joiner that the tenant built are executed. The welcome mail, the manager-change mail and the leaver mail are notification rules on the joiner, mover and leaver events, seeded switched off in every tenant (see starter packs and lifecycle mails). A joiner default proposed by role mining can be accepted on the Lifecycle Joiner card.
• Birthright access comes from access grant policy matches (including bare-account grants, for example "every employee gets an Active Directory account"). Recomputing the Expected access and reconciling drives provisioning; there is no separate JML provisioning path.
• When the start lies in the future, the joiner stays in progress until the start. A hire who leaves before starting has the joiner cancelled.

Before the start, and before activation

A pending hire and a joiner waiting for an onboarding activation (for example an open onboarding case) are held the same way: nothing is granted until the start or the activation. What can be prepared earlier is the tenant setting Before activation, and nothing is prepared earlier than the tenant's pre-validity window before the start:

• Accounts only (the default): the accounts are created disabled on every system whose create can land disabled. Every grant waits.
• Accounts and access: the accounts are created disabled and the grants are written onto them, but only where a disabled account actually stops access. By default that is Active Directory, Entra ID, Google and SCIM; it is a per-system setting under Systems → Provisioning & governance. Elsewhere (an API key, a shared secret, a local login that outlives the disabled flag) nothing is created until the start or the activation.

Entra ID accounts are created disabled like the others when the system's create call sends the enabled flag as a typed value, which the built-in create rows do. A create call saved earlier that still sends a fixed "enabled" keeps creating the account at clearance until it is saved again. B2B guests are never invited early; they wait for the activation.

For a pending hire two things go further than for the gate: an account that already exists and is enabled is disabled until the start, and on a system whose create cannot land disabled the account is created and then disabled, where the system and account type allow disabling. An account type with an early-enable setting stays the exception.

At the start (or at the activation) the status flips and the same reconciliation run enables the accounts and writes the grants that waited, so the lead time is not lost. A password rule that delivers "at creation" waits for the enable where the platform regenerates the password then (Entra today), so nobody receives a password for an account that cannot be used for weeks.

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. For a person with employment rows these fields are derived from the main employment, and a derived change fires the mover event just as a synced one does. A changed department on an employment row is a new row, not an edit. When an HR feed delivers only dates and the platform generates the person's employment row, that row follows the feed's department, cost centre, location, company and function, so a move recorded in HR raises a mover event and not only a new manager.

• Expected-access recompute: what access belongs to the new position?
• 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 → lapse after the after a move post-validity, 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.
• What a mover keeps is set per org dimension (the mover mode), with a hard fallback. The per-context override that could also be edited was never read and is gone; a change that still sends it is refused with a pointer to the replacement. The Mover pane of the Lifecycle settings proposes a mode per dimension from the last 180 days of history (keep with approval when at least a quarter of the access removed at a move was granted back within 30 days, drop when reviewers removed at least 80%), and "Use suggestion" only fills the draft until you save.
• A right carried across a move with approval does not wait for ever. Each dimension in that mode has a review deadline, counted from the person's latest move: the deciders get a reminder three days before, and at the deadline an undecided carry is removed, as a recorded decision that names the deadline (never sooner than three days after the reminder). Per dimension the outcome can be set to keep instead of remove (the default); the Lifecycle settings show both on the dimension's row, and the inbox item says what the deadline will do.

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, 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 (after any post-validity).

The same set drives mover detection when the change arrives through the attribute-mapped HR sync: joining a department or leaving one, not just swapping a single value, fires the mover trigger described above. 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.

Leaver — soft versus hard

A leaver is detected when the identity's lifecycle window closes or when a source that supplies a status says the person is terminated.

• Soft leaver (end date in the future): no action, just an indication in the UI and on the Contexts over time card.
• Hard leaver (window closed, or terminated by status): 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.
• App passwords and tokens survive a disabled account on some systems. Where a connector reads them, a leaver whose credential still signs in is an Advisor finding, and a system can be set to revoke them at the source automatically on leave (off by default). See one person, many accounts.

Many endings at once (a partial feed, a bad export) are judged by the leaver guard and the identity circuit breakers before anyone is terminated. A window that opens again later is a rejoiner.

Not everything called "terminated" is the same thing

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

• A lock (a security lock or an HR-mapped lock) holds everything at once and disables the accounts. No grace. It is reversible: the sources stay, so lift it and the full picture comes back on the next run.
• An explicit decommission (somebody deliberately retired this identity) empties Expected access at once. That call already revoked every assignment when it was made, so a grace window handing access back afterwards would quietly undo a decision a human took.
• A dismissal for cause, a death or a no-show gets no post-validity. A no-show's prepared accounts go down the leaver path.
• A passive leaver (the window ended, or HR terminated the person) is grace-aware. Each entitlement is judged on its own: anything privileged is dropped immediately when the tenant has asked for that, and everything else survives until its post-validity runs out (the policy's own days, else the after leaving default). The grace only keeps what the person had: a policy that starts matching them after the leave date is held, not granted. A request or a review's keep decision is not held. Where the leaver has no account on a system, the grace never creates one and the person is not reported as missing an account there.

The grace belongs to people who leave. An active person whose account drops out of the Expected access (for instance because they changed role) gets no grace: the account is disabled in the same reconciliation run and deleted after the usual disable-then-delete period, even when the tenant or account type has a leaver grace.

The default grace is zero, so nothing changes for a tenant that has not asked for it. The window exists because "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.

While the grace runs, the leaver's identity page says so instead of showing the access as in line. The governance card is yellow with the date the grace ends, and red once it has passed with access still there; it never reads "Healthy" for a leaver who still holds access. On the Access tab each system carries "Leaver grace until …" or how long it is past the grace, and a leaver's grants no longer count as in line. On Contexts over time every context link ends with the identity, marked "ends with the identity"; the HR employment row itself is not changed.

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. It is scoped strictly to genuinely terminated identities, never to a lock, so lifting a lock 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.

Leftover access rows end too. A leaver can keep grant rows that neither the expected state nor the target holds any more: the target dropped the membership, and nothing demands it. Such a row is not access. It is not counted in the person's grants and not shown as drift, so a leaver whose accounts are closed no longer shows a "needs you" banner for it. Once the account type's leaver grace has passed, the next reconciliation run that applies changes removes the row and writes an audit event. Nothing is written to the target, because there is nothing left there. Rows a review is still deciding are kept.

⚠ 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
• Lifecycle coupling