JML in an IGA Program: Turning Identity Data Into Governed, Provable Access Changes

Sara’s promotion

Sara López has spent three years as an analyst in customer operations at an online payment processor. Part of her job is clearing fraud flags that turn out to be false positives: a customer’s card was blocked, she checks the case, and she overrides the flag so the payment goes through. In March she’s promoted to lead the fraud review team, where her new job is to flag suspicious transactions in the first place.

HR records the change on a Friday. Over the weekend the joiner-mover-leaver workflow does what it was built to do: it grants Sara the fraud review team’s access and queues the removal of her customer operations access. On Monday morning, for a few hours, Sara can both flag a transaction as suspicious and clear the same flag as a false positive. Nothing bad happens. But if she had wanted to flag a transaction and quietly clear it herself, the system would have let her, and nobody would have noticed until a review months later. When the internal auditors find the overlap during their spring testing, the question they ask isn’t whether Sara did anything wrong. It’s why the process allowed it at all.

Every step of that workflow worked. That’s the point of this article. A JML engine can run perfectly and still produce a result nobody should trust, and an IGA program’s job is to find out where.

What the foundations article already covered

The JML Cycle, in the foundations domain, explains joiner, mover, and leaver as an operational mechanism: the identity state machine, the four kinds of access (birthright, role-based, requestable, just-in-time), why the mover step is the one programs quietly get wrong, who does what across HR, managers, the IAM platform, and application owners, and the regulations that make all of it mandatory. This article doesn’t repeat that.

It asks a narrower question. Given that a JML workflow exists and runs, how does a governance program know it can be trusted? The previous article built the pieces needed to answer: an authoritative source, a way to match records, and reconciliation. This article puts them to work inside the three events.

What a workflow engine can’t tell you

A JML engine is good at one thing: reacting to an event by running provisioning or removal steps against the systems it’s connected to. That’s necessary work, and it’s what makes joiners and leavers fast. But “the workflow ran and reported success” is a different claim from “the access is now right,” and the gap between them is where governance has to do the work the engine can’t do for itself.

Three gaps show up in nearly every program, and each connects to something from the previous article. The first is whether the event reached the right person, a matching question; the engine trusts whatever record triggered it and has no way to notice the record was a duplicate or the wrong “David in Finance.” The second is whether the event reached every system it should have, a reconciliation question; the engine only knows about systems it has a connector for, and a system without one is invisible to it by definition. The third is whether the resulting access created a new problem, a policy question that’s sharpest for movers, as Sara’s Monday shows; the engine can grant and revoke, but it can’t decide whether the combination it just produced is one the business can live with.

Matching quality decides whether the right accounts get touched

The previous article separated deterministic matching, on a stable shared key, from probabilistic matching, on a scored combination of attributes, and walked through the cases where matching struggles: name changes, rehires, duplicates. Each of those has a concrete consequence inside a JML event, and the consequence depends on which event it hits.

A joiner is the most forgiving, because it usually creates a new identity rather than matching an existing one. The main risk is a rehire treated as brand new, creating a duplicate of a record that should have been reactivated. A leaver is moderately forgiving in the same way: even shaky matching usually finds an account to disable, because whoever triggered it knows roughly who they mean.

A mover is where matching errors do real damage, because it depends on finding an existing record and acting on both halves of it: the old access to remove and the new access to grant. If the HR change is linked to the wrong identity, the result isn’t stale access quietly left behind. It’s an immediate mix-up. The wrong person’s access changes, the right person’s doesn’t, and nobody notices until the person who was actually promoted complains that they still can’t do their new job while someone else, mysteriously, can.

flowchart TD
  accTitle: Matching confidence decides how a JML event proceeds
  accDescr: An HR event goes through identity matching, which classifies the match as high confidence or as low confidence or ambiguous. A high-confidence match proceeds automatically to the JML workflow. A low-confidence or ambiguous match goes to manual review first. Once the workflow runs, the worst case differs by event: a joiner can create a duplicate identity, a mover can change the wrong person's existing access, and a leaver can disable the wrong account and miss the right one.
  EVENT([HR event: hire, job change, termination]) --> CORR{Matching confidence}
  CORR -->|High| WF[Workflow proceeds automatically]
  CORR -->|Low or ambiguous| REVIEW[Manual review first]
  REVIEW --> WF
  WF --> RISK{Which event?}
  RISK -->|Joiner| J[Worst case: duplicate identity]
  RISK -->|Mover| M[Worst case: wrong person's access changes]
  RISK -->|Leaver| L[Worst case: wrong account disabled]

Two Davids in Finance

A mid-sized retailer has two employees named David in finance: David Okafor in accounts payable and David Chen in financial planning. Neither has an identity ID filled in on the old expense system that predates the company’s IGA platform. HR promotes David Chen to a manager role with approval authority. The mover event fires, matching falls back to a probabilistic score on that system because there’s no shared key, and the score, based on first name, an ambiguous last-name initial in a data export, and department, links the promotion to David Okafor’s account.

The workflow runs flawlessly. It removes what it believes is the old access and grants the new approval authority, on David Okafor’s account, and reports complete success. David Okafor now has expense approval rights he never asked for and shouldn’t have. David Chen, the one actually promoted, still can’t approve anything and files a ticket asking why his promotion “didn’t work.” From the engine’s point of view nothing failed; every step was correct for the identity it was confident enough to act on. The failure happened one step earlier, in matching, which is why a program that only watches workflow success rates can’t see this kind of error at all.

The lesson isn’t that matching must be perfect before JML can run. That bar is never met in a real program. It’s that the engine should expose its matching confidence as part of each event, and low-confidence matches should go to a person before a mover or leaver step runs, instead of letting the engine act on its best guess.

Reconciliation proves an event actually finished

Reconciliation, in the previous article, was the regular comparison between the governed state and the real one, catching drift from changes made outside the process. Inside JML it has a second job: turning “the workflow reported success” into “we can show this happened everywhere.”

That matters because the engine’s report only covers the systems it has connectors for. A leaver event that disables the person in Active Directory, the HR system, and every connected SaaS application can still leave them with access to a system nobody ever connected: a legacy application, a vendor portal, a shared password vault. The engine reports full success on everything it touched and has no way of reporting on what it never knew existed. Reconciliation, run against a fuller inventory of systems than the engine’s connector list, asks each system whether the person still has access and flags any that says yes.

It works in the other direction for joiners. Reconciliation confirms that the access that was supposed to be granted actually arrived, instead of assuming a queued provisioning job finished because nothing raised an error. For movers it confirms both halves: the old access is really gone and the new access really works, including in systems with no connector.

The practical habit is to treat the engine’s completion status as a claim for any system that carries real risk. The next reconciliation after a leaver, mover, or high-risk joiner is what turns the claim into evidence, and the gap between “workflow said done” and “reconciliation confirmed done” is worth tracking on its own as a sign of the program’s health.

Joiners: someone has to own the bundle

The foundations article covers the mechanics of a joiner well: preparing accounts before the start date, activating on day one, holding back some access until probation ends. What it takes for granted is the content of the bundle, the specific entitlements that “birthright” or “the standard access for this job” turn into. That content isn’t something the engine invented. It’s a decision someone made once, and it keeps applying to every future hire until someone changes it.

Most programs miss what follows from that. A birthright or role bundle needs an owner and a review date like any other policy, or it drifts out of date the same way an individual’s access does. A department reorganizes and its standard bundle still includes a tool the team stopped using two reorganizations ago. The bundle for a customer operations analyst was defined correctly once and never revisited as the applications underneath it changed, so every new analyst for two years has received something they don’t need. Nobody approved that specifically. Nobody owned the job of noticing.

The discipline is simple to state and easy to skip. Every bundle needs a named owner, usually the business or application owner who already approves requests for that system, and a scheduled review of the bundle’s definition, separate from reviews of any one person’s access. A bundle nobody has looked at in over a year is as much of a finding as an entitlement nobody can justify, multiplied by everyone who was onboarded with it in the meantime. Later in this domain, the articles on role engineering and policies and birthright access go into how those bundles are designed and assigned.

Non-employees: a different source and a different rhythm

The previous article drew a line between the HR system as the authority for employees and a vendor system or registry as the authority for contractors and other non-employees. JML is where that line starts to change how the lifecycle behaves.

A contractor’s joiner looks much like an employee’s: birthright plus job-specific access, provisioned against a start date. The leaver is different in a way that matters. An employee’s departure is usually triggered by something HR records: a resignation, a termination, a retirement. A contractor’s is more often triggered by nothing happening: the contract reaches its end date and no extension is recorded. So the process has to treat “end date reached with no renewal on file” as a trigger in its own right, instead of waiting for someone to report that the contractor has gone. A program that only reacts to explicit terminations, copying the employee pattern, misses every contractor whose engagement simply lapses, which is exactly the gap the previous article warned about.

Renewals are where this gets awkward. Contracts are often extended late, after the end date has passed, because the paperwork moves slower than the work. If the end date triggers removal on time, a contractor who is still working loses access on a Monday and spends a day waiting while procurement records the extension. Some programs accept that friction as the price of a reliable control. Others send a warning to the contractor’s sponsor two weeks before the end date, so extensions get recorded in time, and allow a sponsor to grant a short, logged extension of a few days while the paperwork catches up. What doesn’t work is quietly disabling the end-date trigger for contractors who complain, which recreates the original problem one exception at a time.

Partner users who sign in through federation sit almost entirely outside this organization’s JML process. Their own employer runs their joiners, movers, and leavers. The only lever here is reacting quickly when the partner’s federation assertion stops arriving or is revoked. There’s no mover to design, because this organization was never the authority on that person’s job; the governance question shrinks to how fast access actually stops when the partner’s signal stops.

Movers: a policy question hidden in a workflow step

The foundations article explains why the mover is the hardest event operationally: the removal half gets skipped because nothing forces it, and skipped removals pile up as privilege creep. IGA adds a second problem to the same event, which Sara’s Monday illustrates. For the time a mover holds pieces of both the old job and the new one, is that combination something the business can tolerate?

In Sara’s case the two entitlements, flagging a suspicious transaction and clearing a flag as a false positive, are each perfectly reasonable on their own. Together they let one person both raise and quietly dismiss the same case. A procurement analyst moving to treasury produces the same shape of problem with different names: creating vendor records from the old job and approving payments to vendors in the new one. The separation of duties module later in this domain builds the detection logic for these combinations in full. The point here is narrower: a mover event is one of the specific moments when a new conflict is created, which makes it the natural place to check for one.

A program that only checks for conflicts in a quarterly review will eventually catch Sara’s. “Eventually” might mean three months in which she could flag and clear the same case. A program that checks at the moment of the mover, evaluating what remains of the old access together with the new grant before the grant goes through, closes that window to nothing.

That’s what happens in the better version of Sara’s promotion. The mover event fires, and before granting the fraud review access the workflow evaluates it together with her remaining customer operations access. The check finds the conflict and sends it to the fraud review application owner, the owner of the higher-risk side. The owner chooses the safer path: Sara’s override access is removed first, reconciliation confirms it’s gone, and only then is the new access activated, a day later than an unconditional grant would have been and with no moment in which the conflict existed.

Not every conflict a mover check finds should block the change. Sometimes the business genuinely needs someone to hold both pieces for a handover, or a small team has a role that legitimately spans what policy would forbid. What the check changes is how that’s handled. Instead of existing silently, the conflict surfaces at the moment it’s cheapest to deal with, and it’s either resolved by removing the unneeded old access or explicitly accepted, with a compensating control and an owner’s name on the decision.

sequenceDiagram
    accTitle: A mover event triggers a separation-of-duties check before the new access is granted
    accDescr: The HR system sends a mover event to the JML workflow. Before granting the new access, the workflow checks the remaining old access plus the new access against separation-of-duties policy. If there is no conflict, the grant proceeds. If there is a conflict, it goes to an exception approver, who approves with a compensating control or denies. Either way, the finding is logged for the next certification.
    participant HRIS as HR system
    participant WF as JML workflow
    participant SOD as SoD check
    participant APR as Exception approver
    HRIS->>WF: Mover event
    WF->>SOD: Remaining old access + new grant
    alt No conflict
        SOD->>WF: Clear
        WF->>WF: Grant new access
    else Conflict found
        SOD->>APR: Exception review
        APR->>WF: Approve with compensating control, or deny
    end
    WF->>WF: Log the finding for certification

When JML needs a person

Most of a well-run JML process is automatic, but a few steps deliberately need a human: a manager confirming which deferred access a new hire should receive after probation, an owner deciding on a conflict like Sara’s, someone resolving a low-confidence match. Those steps are where JML events stall, and how a program handles a stalled step matters.

Each human step needs a service level, a reminder, and an escalation path, the same way an access request does. And each needs a defined outcome when nobody responds. For grants, the safe default is to wait or to escalate, never to approve automatically; an event that grants access because a manager didn’t answer in three days has turned silence into an approval. For removals, the default should be the opposite: if an owner doesn’t respond about whether a mover’s old access is still needed, the access goes, and can be requested back through the normal process if it really was needed.

It’s worth watching how many JML events are waiting on a person at any moment, and for how long. A growing queue of stalled movers is usually the first sign that old access is quietly being left in place.

Leavers: from fast to provable

Speed is the right headline for a leaver, and the foundations article covers the urgency levels and the disable-then-delete sequence well. The governance question on top is different. When an auditor, a regulator, or a cyber insurance questionnaire asks you to prove that a person’s access was removed everywhere by a given date, what do you hand over?

In a program without reconciliation, the honest answer is a workflow log showing the systems the engine reached, plus an assumption that nothing was missed. A program with reconciliation built into the leaver process has a second, independent confirmation: every connected system was checked afterwards and the access is gone, with a timestamp separate from the one on the original trigger. That second timestamp is what a mature program reports as its real time to remove access, because the first one can look excellent while hiding the systems the workflow never reached.

A healthcare provider, the same one from the previous article’s 340 unmatched accounts, runs its first reconciliation-based check of leavers. Of the last 200 terminations processed by its workflow, 187 show clean removal from every reconciled system within 24 hours. The other 13 all trace to the same cause: a clinical scheduling application that predates the IGA platform and never got a connector, so every leaver event skipped it. The engine’s own reports never flagged one of the 13, because as far as it knew it had done everything it was asked. Reconciliation turned an invisible 6.5% failure rate into a named gap and, in the end, into a business case for building the missing connector.

“Show me this person’s access was removed” sounds like a single fact, but the evidence behind it has several parts, and a program without reconciliation usually has only the first two.

A program that can produce only the first two rows is describing what it attempted, not what it achieved. Experienced auditors probe for exactly that difference, because “we triggered the process” and “the access is gone” are the two claims that diverge whenever connector coverage is incomplete.

What actually gets granted and removed

Every event in this article, the joiner’s birthright and role bundles, the mover’s removal and grant, the leaver’s full removal, acts on entitlements. So far this article, like the foundations one, has treated “the standard bundle for this job” and “the access tied to the old job” as if they were obviously well defined. In a real program they often aren’t. Names are inconsistent across systems, nobody owns half the entitlements in a typical bundle, and “role” is often an informal label rather than a governed object with a current definition.

JML is the process; the entitlement catalog is the inventory of what that process moves around, and a JML workflow is only as trustworthy as the catalog underneath it. A perfectly fast, perfectly matched, perfectly reconciled mover that grants “the standard fraud review bundle” only means something if there’s a current, owned definition of what that bundle contains. The next article builds that catalog.

Plenty of real implementations build the catalog first and wire up the lifecycle afterwards. This module goes the other way on purpose: the failures described here, a mover that skips a removal, a bundle nobody owns, a leaver gap only reconciliation catches, are what make the need for a rigorous catalog concrete, rather than an inventory exercise for its own sake.

Certification catches what JML can’t see in real time

Matching confidence, mover checks, and reconciliation close most of the real-time gaps. What remains is the slower drift that only becomes visible when someone with business context looks at a person’s access and asks whether it still makes sense. That’s access certification, covered in the next module.

A well-instrumented JML process makes certification easier, not just later. A mover that logged its conflict check, what it found, and how it was resolved gives a reviewer something concrete to look at instead of a bare list of entitlements. A leaver with a reconciliation-confirmed completion time means a review never has to ask whether the person actually left and was cleaned up; that’s already answered.

JML is also one of the best sources of when a targeted review is worth running. Some programs send a mover with an accepted conflict straight to the application owner for a quick confirmation, along the lines of “this person now holds both of these entitlements, with this compensating control, does that still look right?”, closing the loop within days instead of waiting for the next quarterly cycle. The moment access actually changed is a much better trigger for a review than an arbitrary date on a calendar. Sara’s accepted exception, if the owner had chosen that route, would have been exactly such a case: a short, targeted review a month after her move, asking whether the compensating control was still in place.

Measuring trust, not just speed

The foundations article lists the operational measures worth tracking: time to provision, time to remove, automation rate, orphan rate, signs of privilege creep, conflict counts. Governance adds a few that measure whether the process can be trusted rather than how fast it runs.

The share of JML events with a high-confidence match shows how much of the population the process can act on without manual review; a fast workflow with low matching confidence is fast at possibly touching the wrong person. The gap between workflow completion and reconciliation confirmation shows how long a “done” claim goes unverified; time to remove access looks great if it’s measured against the workflow’s own timestamp. The share of mover events with a logged conflict check shows whether the riskiest event is actually checked when it matters. And the number of systems reconciled compared with the number connected shows how much of the real environment the program can vouch for, since a perfect success rate on a partial connector list isn’t complete coverage.

Rehires, leaves, and other edge cases

A handful of situations break JML processes designed around the typical employee, and each is worth a rule before it happens rather than an improvised fix after.

A rehire who left eighteen months ago may come back with a new HR record or with the old one reactivated, depending on how HR works. If the old record is reactivated, the workflow may restore access from the previous job; if a new one is created, matching may fail and leave the person with two identities. Either way the decision should be made deliberately, and old access should never come back automatically just because a record was reactivated.

Long leaves, whether parental, medical, or sabbatical, aren’t departures, but they shouldn’t leave full access active for months either. Many programs suspend everything except email and HR self-service for the duration and restore it on return through the same governed process, so returning employees get their current job’s access rather than a frozen snapshot.

Internal transfers between legal entities, common after acquisitions, can look to HR like a leaver in one company and a joiner in another on the same day. Handled naively, the person loses everything on Friday and waits a week for access on Monday. Handled well, the program recognizes the pair as a mover and applies the mover rules, including the conflict check.

The loop from article 1, applied to one event

The first article in this domain described IGA as a loop: administration carries out changes, governance decides and verifies. A JML engine is squarely administration, the machinery that provisions, assigns, and removes on schedule and on trigger. Everything this article added, matching confidence deciding what the engine may act on, a conflict check at the mover’s moment, reconciliation confirming what happened, certification using the evidence trail, is governance wrapped around the same three events. It turns “the workflow ran” into something a program can stand behind when asked to prove it.

Neither half replaces the other. The foundations article is what makes joiners and leavers fast and gives movers a fighting chance. This one is what makes the result trustworthy enough to survive an audit or a reviewer’s honest scrutiny. A program that invests only in administration ships a JML process that looks fast and falls apart the first time someone asks for proof; one that invests only in governance designs excellent policy on top of a workflow that can’t carry it out.

Recap

• A JML workflow engine carries out access changes, but can’t confirm by itself that it reached the right person, reached every system, or avoided creating a new problem.
• Matching confidence should gate events, especially movers, where a bad match changes the wrong person’s access instead of leaving stale access behind.
• Reconciliation turns “the workflow reported success” into evidence, especially for systems outside the connector list.
• Bundles need owners and reviews; contractors need end dates treated as triggers, with a sponsor warned before the date so renewals are recorded in time.
• Human steps in JML need service levels and safe defaults: grants wait or escalate when nobody answers, removals go ahead.
• Mover events are the natural moment for a separation-of-duties check on the combined old and new access, as in Sara’s move to fraud review.
• A well-instrumented JML process feeds certification with evidence and good moments to review, and should be measured on trust as well as speed.

Three questions to test yourself

1. A mover event finishes with the workflow engine reporting full success. Name two things that could still be wrong without the engine ever noticing, and which mechanism in this article catches each one.
2. Why does this article argue that the conflict check belongs at the moment of the mover rather than in the next scheduled review, and what does waiting actually cost?
3. An organization reports excellent time to remove leavers’ access, based entirely on workflow timestamps. What would you ask before trusting that number?

Hands-on exercise

Take a job change you know about, your own or a colleague’s, real or imagined.

1. List the access the person held in the old job and the access the new job needs, across at least three systems.
2. Mark any pair, one from each list, that would be a problem if one person held both, and decide whether the old access should be removed before or after the new access is granted.
3. Describe what evidence you would want afterwards to prove the old access was really removed everywhere.
4. Write down one edge case from this article (a rehire, a long leave, a transfer between entities) and the rule you would set for it.