Joiner-Mover-Leaver Automation: How IGA Makes It Work

Every employee generates the same three access events over their career: they join, they move, and eventually they leave. Each event should trigger a matching change in access, which is precisely the job that joiner-mover-leaver automation is built to carry out. However, improper handling of JML events can result in orphaned accounts or excessive accumulation of access rights. A recent EMA survey of 135 IT decision-makers and practitioners found that they name overprovisioning and privilege creep as the most pressing risk facing their organization, more than double the share who cite insider threats.

What is joiner-mover-leaver (JML) automation?

Joiner-mover-leaver (JML) automation uses role definitions and policy to decide what access someone should have at each defining moment of employment: joining an organization, moving within it, and leaving it. Instead of a service desk agent or line manager deciding case by case what a hire, transfer, or exit should mean for someone’s access, a policy engine applies predefined rules automatically, tied to role, department, and business context.

JML automation is the operational core of identity lifecycle management, the broader discipline that governs an identity’s entire relationship with an organization. Joiner, mover, and leaver events are the highest-volume moments inside that lifecycle. If a company is able to automate those three well, they have, effectively, automated the large majority of its identity lifecycle workload. Less frequent events, such as a leave of absence or a return after a career break, sit outside JML’s three core triggers but inside the same lifecycle, and the automation logic can often carry over directly. For instance, a leave suspends access in the same way a leaver event disables it, and a return re-provisions against whatever role currently applies rather than restoring whatever access the person held before they left.

Joiner: getting access right on day one

A joiner event fires when someone new enters the organization, whether as an employee, a contractor, or a non-human identity such as a service account or an AI agent. Automation compares the new record against a defined role and provisions access to the systems, applications, and file shares that role requires, so a new hire in finance has ERP, expense, and email access waiting on day one.

Mover: where JML automation must grant and revoke together

A mover event fires whenever someone’s role, department, or responsibilities change, through a promotion, a transfer, or a reorganization. This is the event that should both grant new access and remove old access. It is also, as the next section covers, the event that is likeliest to be handled in an incomplete manner.

Leaver: removing access completely and on time

A leaver event fires when employment ends, voluntarily or otherwise. Automation disables accounts and revokes entitlements across every connected system as soon as the system picks up that change in the HR record, closing the window between someone’s last day and the day their access stops working.

Benefits of joiner-mover-leaver automation

The case for automating these three events breaks down into four measurable gains.

Efficiency

JML automation removes the manual decision points that slow down onboarding and transfers. A new hire’s access gets provisioned against their role automatically, instead of waiting on a ticket routed to three different system owners. The same policy engine handles routine grants and revocations at every mover event, without depending on someone remembering to act.

Security

JML automation closes access down as reliably as it opens access up, when it is built to do both. An employee who moves from sales into finance should lose CRM export rights the same day they gain access to the general ledger. Left alone, they keep both indefinitely. Applied consistently at every leaver and mover event, this same logic eliminates the orphaned accounts and stale entitlements that attackers look for first.

Compliance

Role- and policy-driven access changes keep segregation of duties (SoD) rules intact through every transfer. Without that enforcement, a mover event can quietly hand someone both invoice-creation and invoice-approval rights, a toxic combination manual processes rarely catch before an audit does. Automated JML checks each grant against policy before it applies, so conflicting entitlements never make it through.

Audit readiness

Auditors can trace exactly why someone has access, because every automated grant and revoke ties back to a specific role and policy. For an employee with several moves in their history, that turns a multi-day log reconstruction exercise into a query.

Where JML automation typically breaks down

Joiner and leaver events are binary: an account either needs to exist, or it doesn’t. A hire record appears in HR, and the system creates an account against a starting role; a termination is recorded, and the account gets disabled. Both have a clear trigger and a checkable outcome.

However, a mover event isn’t as binary or straightforward as a joiner or leaver event. It asks a judgment question that an HR record alone can’t answer: which of this person’s existing access is still justified, and which isn’t. A promotion or transfer is a legitimate reason to grant new access, but it is not, on its own, evidence that old access should be removed. If improperly handled, the result of mover events is additive: people gain access with every move and rarely lose any.

Why JML automation belongs inside IGA

HR systems and service desks record that an event happened: a hire date, a transfer, a termination. However, they are not built to decide what access that event should trigger, because that decision depends on role definitions, SoD rules, and entitlement mappings that live in a governance layer.

Running JML logic out of HR workflows or ITSM tickets means rebuilding a policy engine, informally, inside a system that can only loosely approximate the complicated decisions that determine correct JML automation. Identity governance and administration (IGA) allows companies to use a purpose-built platform for this job: it holds the role model, policy rules, and entitlement catalog in one place, and enforces decisions consistently across every connected application. This results in consistent visibility and reliable security in JML automation.

A correctly architected IGA platform treats a role or department change as one policy event with two actions: grant what the new role requires, and revoke what the old role no longer justifies, in the same trigger.

What to look for in an IGA solution for JML automation

Not every IGA platform automates movers with the same rigor it applies to joiners and leavers. Before choosing one, check whether it treats every role change as a symmetric grant-and-revoke event rather than a grant-only one, whether its role model can be updated by business owners without a development cycle, and whether its access certification process can prove, on request, why a given person has the access they currently hold.

Omada Identity Cloud runs joiner, mover, and leaver events through one policy and governance engine, so revocation happens with the same rigor as provisioning.

Go back to the last person on your team who changed roles. Check what access they gained against the new job, then check what followed them from the old one. If nobody can answer that second question with evidence, that’s the gap JML automation, run inside IGA, is built to close.

See how Omada governs joiner, mover, and leaver events as one connected process. Schedule a demo to get started.