Why Mover Events Are Where JML Automation Actually Breaks

Joiner-Mover-Leaver gets discussed as one lifecycle, but in practice it’s really three different design problems, and two of them get most of the attention. Joiners are visible and business-critical — a new hire who can’t work on day one generates immediate complaints, so joiner provisioning gets built and tested carefully. Leavers are tied to a clear HR trigger (termination) that’s relatively easy to automate around. Movers sit in between, and in my experience they’re the ones that don’t get designed properly.

The gap: additive-only thinking

A mover event — a transfer, a promotion, a department change — should trigger two things: new access appropriate to the new role, and removal of access that was only justified by the old one. Most implementations I’ve seen handle the first half well and the second half poorly or not at all, because a mover is often modeled internally as “run the joiner process again” without a corresponding revoke step.

The consequence isn’t visible immediately. It shows up eighteen months later as an access certification finding: someone in their third role at the company still holding entitlements from their first two.

Why this is easy to miss in design

A few reasons this gap persists:

• Revoke logic requires knowing the “before” state, not just the “after” state — which means the lifecycle engine needs to diff the old role’s birthright access against the new role’s, not just grant the new role’s entitlements additively.
• Business urgency is asymmetric. Nobody escalates “I still have access I don’t need.” Missing access blocks work and gets fixed fast; excess access is invisible until an audit or certification catches it.
• Role-to-role transitions aren’t always clean. Someone moving from an individual contributor role to a people-manager role, or across departments with overlapping responsibilities, doesn’t always map to a simple “remove role A, add role B” — sometimes deliberate overlap is legitimate, and the lifecycle engine needs a way to express that rather than defaulting to pure additive provisioning.

What I’ve found actually helps

Explicitly designing the mover path as its own case — not a variant of joiner — with an explicit delta calculation (add what’s new, remove what’s no longer justified) between old and new role entitlements. Triggering a targeted access review on significant transfers, rather than waiting for the next scheduled certification, so accumulated access gets caught closer to when it happens. And treating “access that’s outlived its justification” as a governance metric worth tracking on its own, not just something a certification campaign happens to catch every few months.

None of this is complicated conceptually. It’s just easy to skip when joiner and leaver automation are the parts everyone’s watching.