No workflow in enterprise IT sounds more automated than joiner-mover-leaver, and none is less automated in practice. Every large organization owns an IGA platform that "does JML." Every one of them also runs a parallel economy of tickets, scripts, and manual fixes that does the parts the platform cannot. The gap is not a maturity problem that more configuration will close. It is structural — and it lives in the handoffs.
A cross-system workflow run as single-system automations
A single joiner event fans out across at least five domains: an account and group memberships in Active Directory, a synchronized identity with licenses and conditional-access assignments in Entra ID, a mailbox with delegation and distribution lists in Exchange, vault enrollment and privileged-role eligibility in PAM for technical hires, and entitlements across dozens of business applications. These systems have different protocols, different consistency models, different failure modes — and, critically, ordering dependencies between them: the mailbox needs the synced identity, the license needs the group, the PAM enrollment needs the account.
IGA connectors automate each system individually. The sequence — the cross-system transaction with its orderings, waits, and rollbacks — is nobody's product. It is stitched together with sync-cycle timing assumptions and scheduled scripts, and when one step fails silently, nothing above it knows. The workflow completes in the IGA platform's view and fails in reality. This is the identity execution gap in its most visible form, described generally in The Identity Execution Gap.
Partial automation and the exception economy
The standard implementation automates the modal case: standard employee, standard department, standard entitlements. Everything else — contractors, mergers, shared mailboxes, name changes, rehires, cross-forest moves, the executive who needs access on day zero — routes to exception handling, which means a ticket and a human. Two dynamics make this worse than it sounds:
- At enterprise scale, exceptions are not the tail. A workforce with contractors, acquisitions, and matrix structures generates enough non-modal events that the "exception" path handles a substantial share of total volume — by hand, at ticket-queue latency, with hand-crafted variance in the outcome.
- Exception handling erodes the automated path. Every manual fix leaves state the automation did not create and does not expect. The next automated run collides with the hand-made state, fails, and generates another exception. Ticket volume becomes self-sustaining.
The residue accumulates as orphaned access: the leaver whose AD account was disabled but whose application entitlements survived, the contractor mailbox still delegated to a departed manager, the service credential enrolled for a project that ended. Certification campaigns exist to sweep up this residue — an expensive, quarterly admission that execution and intent have diverged.
The mover is the hardest case
Joiners start from nothing; leavers end at nothing. The mover starts from one populated state and must arrive at another — which makes it a diff, not a template. Computing that diff correctly requires knowing what the person currently has (across every system, including what exceptions granted by hand), what the new role requires, what must be removed, what must be retained through a transition period, and in what order the changes can safely land. Manual operators resolve this ambiguity the safe-feeling way: add the new access, defer the removals. Every mover thus becomes an accumulator, and long-tenured employees end up with the union of every role they have ever held — the exact profile that fails audits and delights attackers. The mover case cannot be fixed with better intentions; it requires machinery that can read actual state, compute the delta against intended state, and execute the removals with the same reliability as the additions.
Joiners and leavers are templates. Movers are diffs — and diffs are exactly what ticket queues and scripts execute worst.
What protocol-bound execution changes
Treat each JML event as an execution contract rather than a workflow of tickets, and the failure modes above are addressed by construction. The contract binds the entire cross-system sequence before anything runs: every operation, every target object in AD, Entra ID, Exchange, PAM, and the application tier, the ordering constraints between them, the authorization it derives from, and the expected end state of every system touched. Execution then proceeds through native protocols under just-in-time credentials — no standing service-account power, per Zero Standing Privilege — and, decisively, every step is verified: the executing layer reads the target system back and confirms the state matches the contract before the step is marked done.
Verification is what kills the silent partial failure. A sync that did not converge, a license that did not apply, a removal that did not take — each surfaces at execution time as a contract-level discrepancy with a defined remediation, not three weeks later as a user complaint or three months later as an audit finding. And because the mover contract is computed from actual read state, not assumed state, the diff problem becomes tractable: removals are first-class contracted operations, verified like everything else, rather than deferred good intentions.
Audit by construction
Under this model the evidence a JML audit requires is not assembled afterward — it is the execution record itself. For every joiner, mover, and leaver: the authorizing decision, the full contract, each protocol call, each verification result, sealed at completion. "Show me that this leaver's access was fully removed, everywhere, and when" stops being a two-week reconstruction across ticket comments and sync logs and becomes the retrieval of one record. Recertification shrinks correspondingly: a campaign that exists to find divergence has less to find when divergence is detected and remediated per event.
Metrics that show it is working
A JML program fixed at the execution layer proves itself with a short list of numbers, each trending the right way within a quarter or two: time from HR event to verified completion across all systems (leavers measured in minutes, not days); percentage of JML events completing end-to-end without human touch; exception rate, and its direction; orphaned accounts and entitlements discovered per certification cycle (the residue metric — it should decay toward zero); mover access-removal completion rate (the honest measure of the diff problem); and audit-evidence retrieval time per event. Note what is absent: ticket closure time. When execution is contracted and verified, the ticket stops being the unit of work at all.
This is the workload CAELION's Cube23 was built for: JML across Active Directory, Entra ID, Exchange, and PAM executed as protocol-bound, verified, evidence-backed contracts — adjacent to the IGA platform that owns the decisions, and to the ITSM and HR systems that trigger them. To walk through a mover contract against your own environment, request a briefing.