Joiner-mover-leaver (JML)

Joiner-mover-leaver, usually shortened to JML, is the model for managing a person's access across the whole of their time at a company. There are three stages, and each one should change a person's access to match: they join, their role changes, and they leave. Every stage should apply automatically and across every system. The model is old and the stages are obvious. What is not obvious is that most companies handle the first and last stages by hand and skip the middle one entirely.

The vocabulary comes from HR, where the three words describe the three kinds of personnel action.

The term leaver is a common HR term. As in joiner, mover, leaver, being three different types of common HR actions (onboarding, team changes, and offboarding).

HR event:      hired                    changed team                  left
                 |                           |                           |
                 v                           v                           v
JOINER: grant the role's bundle    MOVER: add the new role's    LEAVER: remove everything,
        on day one                        access...                     everywhere, in one run
                                          ...and REMOVE the old
                                          role's access
                                          (the step that is skipped)

What are the three JML stages?

Each stage has a trigger, an expected change in access, and a characteristic way of failing.

Joiner

A new hire needs access to the applications their role requires, ideally on day one and not after a week of tickets. When that access is driven by policy rather than a manual request queue it is called birthright access: the role maps to a bundle, and the bundle is granted automatically. A commenter on a thread about SCIM described what the joiner stage looks like when it works:

Deprovisioning is huge. Provisioning is also awfully nice. For example: 1. New employee joins the team. 2. SCIM creates their account in the ticket tracking system. 3. Employee's boss can create onboarding tickets and assign them to the new person before they've even logged into the system.

Mover

Someone changes team, gets promoted or shifts function. Their access should change to match, gaining what the new role needs and losing what the old role required. This is the stage that quietly fails, and it fails asymmetrically. The new access has an advocate, because the person cannot do the new job without it, so somebody chases it. The old access has no advocate at all. Removing it helps nobody this week, costs the person their fallback, and risks breaking a report that still matters. The safe move is always to leave it in place.

Leaver

Someone departs, and all of their access is removed across every system, sessions are ended, owned data is handled, and the whole thing is recorded. This is deprovisioning, and it is the stage where a miss becomes an orphaned account.

Where does JML break?

Two structural problems account for most of the failures, and neither is carelessness.

The mover stage is not an event

The joiner and leaver stages are events that somebody notices. Someone starts or someone quits, and processes get built around dates that already sit in a calendar. A team change is a quiet administrative update, and the access implications trail behind it by weeks or never arrive at all. The result is privilege creep, which is simply access accumulating as people move around while the grants from prior roles stack up behind them. By the time an access review runs, a five-year employee who has changed teams three times is carrying permissions from all three, and nobody can say why they still have most of them.

Identities outside the HR system have no trigger

JML runs cleanly when there is one authoritative source firing the stages, and the HR system plays that role for employees. Contractors, service accounts, agency staff and other identities that never touch the HR system have no automatic trigger. Their lifecycle is managed from memory, if it is managed at all, and their leaver stage often never fires.

What changes for apps without SCIM?

With SCIM available on the right plan tier, the three stages run from the directory. A joiner record creates the account, a role change updates the groups, and a leaver is deactivated. Without it, each of the three stages is a ticket for a person to work.

What the protocol actually carries

The three stages map onto three protocol operations, which is why the SCIM row is the clean one. RFC 7644 defines a POST that creates the resource, a PATCH that modifies part of it, and the same PATCH used to flip the account inactive. The mover stage is the interesting one, because a PATCH can add a group membership and remove another in a single request. An application that implements the protocol therefore gets symmetric moves for free, and an application outside it gets whichever half somebody remembered.

Why the mover row is the expensive one

Joiners and leavers outside SCIM are at least visible. Somebody is waiting for access, or somebody has left, and in both cases a human is watching the calendar. A mover produces no such pressure, so the ticket that adds the new access gets filed and the ticket that removes the old access never does. The cost compounds with tenure rather than with headcount, which is why it surfaces first in the applications the longest-serving staff use.

What a second path has to do

In a typical mid-market stack the second and third rows describe most applications, so JML ends up automated for a minority of systems and manual for the rest. Working JML needs a second path, over the application's API or through automation that drives the admin console, so that the applications without SCIM respond to the same three triggers. Two properties make that path worth having, and both concern parity with the SCIM row. It has to be driven by the same trigger rather than by a separate queue. It also has to write the same record, so that a leaver sample reads identically whichever row an application sits in.

What does working JML look like?

The HR system is the source of truth, and every stage runs from it in the same order.

1. A joiner record is created, and the birthright bundle for the role is granted across every connected application before the start date.
2. Access beyond the bundle is requested, approved and recorded through a request flow, so that the exceptions are known.
3. A department or title change fires the mover workflow, which adds the new role's access and removes the old role's access in the same run.
4. A termination date fires deprovisioning everywhere in one sequence, including tokens, ownership transfers and the record.
5. Identities outside the HR system carry an explicit owner and an expiry date, so that the same machinery covers contractors and non-human accounts.

The rule that makes the fifth step work

Identities outside the HR system are the reason most JML programs cover four stages instead of five. A contractor, an agency designer or a service account has no personnel record, so nothing fires on their behalf and nothing expires. The correction is to require two fields on every identity the HR system does not own. One is a named human owner, and the other is a date after which the identity stops. The owner gives the review something to route to, and the date gives the leaver stage a trigger it can fire on without anyone remembering.

Adds and removes in the same run

The other rule concerns pairing, and it applies to both ends of the arc. Every grant on the joiner checklist has a mirror on the leaver checklist. Every mover change adds and removes in one operation, rather than in two tickets that can be worked separately. Pairing them is what stops privilege creep at the source, because an unpaired add is precisely what a review has to find months later. A Hacker News thread on leaving a job well put the first half plainly: whenever something is added to the onboarding checklist, add it to the offboarding checklist as well.

Iden runs the three stages as workflows fired by the HR system: an onboarding bundle per role, a transfer workflow that adds the new access and removes the old in the same run, and an offboarding workflow that reaches every connected application. The Workflows screen groups them under Onboarding, Transfer and Offboarding and shows which applications each one touches. The feature behind it is Day one access, without a ticket.

Neun Workflows in drei Gruppen. Entscheidend ist die Spalte mit den Applikationen: Das Basis-Onboarding betrifft 32, ein Standortwechsel nur 3.

The point of JML is that access always reflects the current state of the person rather than the sum of everything they have ever been granted. When it works, there is nothing to clean up later, because nothing accumulated.