Automating Joiners, Movers, and Leavers: The Identity Lifecycle Model Explained

Ask most IT teams how long it takes to fully revoke a departing employee's access, and you'll get a shrug rather than a number. Ask how many accounts in Active Directory belong to people who left the company eight months ago, and the shrug gets longer. This isn't negligence — it's the natural result of managing user identity as a series of manual, one-off requests instead of a defined lifecycle with a beginning, middle, and end.

The Joiners-Movers-Leavers (JML) model gives that lifecycle a name and a structure. It's a simple idea with outsized security consequences: every employee's relationship with your systems moves through exactly three transitions — arriving, changing roles, and departing — and each one is an access-control event whether you treat it as one or not. This article covers what the JML model actually involves, why doing it by hand creates real risk, and the automation patterns — HCM-triggered provisioning, structured approval workflows, and event-driven deprovisioning — that turn it into something reliable and auditable.

What joiners, movers, and leavers actually means

JML breaks the employee identity lifecycle into three distinct stages, each with its own access-control objective:

• Joiners (onboarding). A new hire needs an identity created and provisioned with exactly the access their role requires — no more, no less — ideally available on or before their first day.
• Movers (transfers). An existing employee changes role, department, or location, and their access needs to shift to match — which almost always means both granting new permissions and removing old ones, not just adding.
• Leavers (offboarding). An employee exits the organization, and every credential, group membership, and license tied to their identity needs to be revoked, on a timeline that doesn't leave a window of unnecessary access after their last day.

Underneath all three sits a broader discipline called user lifecycle management (ULM) — the ongoing practice of provisioning, adjusting, and revoking access so that, at any given moment, what an employee can actually reach in your systems matches what their current role requires. JML is the practical shape that discipline takes as three recurring, high-frequency events.

Why manual JML quietly becomes a security problem

Handled manually — spreadsheets, email chains between HR and IT, ad hoc account creation — JML degrades in predictable ways as an organization grows past a couple hundred employees:

• Onboarding drags. Manually provisioning a new hire across Active Directory, email, and a handful of SaaS tools is genuinely time-consuming once you account for coordination between HR and IT, and it directly shapes a new employee's first impression of the company. A new hire who can't log into anything on day one isn't a minor inconvenience — it's a productivity and retention issue from the very first hour.
• HR and IT stay disconnected. When onboarding coordination runs through phone calls, emails, or CSV exports that someone has to manually reconcile, every handoff is a place where a request can get lost, delayed, or misinterpreted — and IT ends up maintaining brittle provisioning scripts that break every time an HR system's export format changes.
• Access provisioning gets miscalibrated. Getting a new hire's permissions right by hand is a balancing act — too little access and they can't do their job, too much and you've created unnecessary risk. Manual processes tend to drift toward "grant broadly and sort it out later," because that's the path of least resistance under time pressure.
• Entitlement creep accumulates silently. Every mover event that only adds access without removing what's no longer needed leaves a residue. Multiply that across years of role changes and an organization ends up with employees holding permissions to systems they haven't touched since a role they left long ago — access nobody remembers granting and nobody is actively tracking.
• External users fall outside the safety net entirely. Contractors and partners often don't exist in the core HR system that would otherwise trigger a JML event, so their accounts get created manually and, too often, never systematically reviewed or expired.
• Leaver access lingers. This is the most consequential failure mode. Deprovisioning across every system an employee touched during their tenure is tedious and easy to partially miss — and it is not unusual for a meaningful share of former employees to retain access to at least one system well after their last day, simply because offboarding stopped at the obvious accounts and never checked the rest.

An access right nobody remembers granting is still a door nobody is watching.

None of these failures require malice or incompetence — they're the predictable outcome of running a high-frequency, high-stakes process through manual coordination. That's the case for automation: not that manual JML is done carelessly, but that it doesn't scale safely no matter how careful the people running it are.

The automation patterns that fix it

Automated JML doesn't eliminate human judgment — it removes the manual, repetitive execution while keeping humans in control of the decisions that matter. Three patterns do most of the work:

HCM-triggered provisioning. Instead of IT waiting for an email from HR, the HR/HCM platform (Workday, BambooHR, UltiPro, and similar systems) becomes the source of truth that triggers identity events directly. The moment HR marks a new hire as active, that record synchronizes automatically with the identity management system — job title, department, manager, and location all flow through — and account creation across Active Directory, Microsoft 365, and Google Workspace happens against a predefined template rather than being assembled by hand each time. The same mechanism handles movers: a role change recorded in HR propagates automatically, adjusting group memberships and permissions to match the new position without a separate manual request.

Role-based provisioning templates. Rather than an administrator deciding permissions case by case, provisioning rules map roles, departments, and locations to predefined access bundles enforcing least privilege by construction. A new hire in a given role gets exactly the access template built for that role — consistent every time, and without the drift toward over-permissioning that manual provisioning tends to produce under time pressure.

Event-driven deprovisioning. The leaver side works the same way in reverse: when HR marks someone's status as terminated or resigned, that single event triggers a defined sequence — group memberships removed, the account disabled, licenses reclaimed, mailboxes handled, and the account moved into a dedicated holding location for departed users rather than left in place among active accounts. Because the trigger is a status change in the system of record, not a task someone has to remember to perform, the timing gap between an employee's last day and access revocation shrinks from days or weeks down to as fast as the HR update itself propagates.

Approval workflows and who should hold the keys

Full automation without oversight is its own risk — nobody wants account deletions or permission grants firing without any check. Mature JML automation solves this with structured approval workflows built around four distinct roles:

• Requester — raises the request for a specific action, such as a new account or a permission change.
• Reviewer — assesses the request, weighs the pros and cons, and makes a recommendation before it goes further.
• Approver — holds the actual authority to sign off on the action.
• Executor — carries out the approved action once authorization is complete.

Splitting these into distinct roles, each configurable per workflow, means no single person can both request and approve their own change — a basic segregation-of-duties control that manual, email-driven processes routinely skip because it's inconvenient. It also means the automation isn't a black box: every account creation, permission change, or deprovisioning action has a documented chain of who asked for it, who reviewed it, and who authorized it, before the system executes anything.

This is precisely the mechanism ManageEngine ADManager Plus (/manageengine/admanager-plus.html) builds around for JML automation — HCM integrations that trigger onboarding, modification templates for movers that adjust group memberships and folder permissions in bulk, and offboarding policies triggered directly off a "resigned" status in the HR system, all wrapped in configurable requester-reviewer-approver-executor workflows so automation never bypasses accountability. For organizations that need this identity lifecycle automation combined with broader governance — access certification campaigns, adaptive authentication, and UEBA-driven anomaly detection across the same accounts — ManageEngine AD360 (/manageengine/ad360.html) extends the same JML foundation into a fuller identity and access management platform.

The compliance angle: why auditors care about JML

JML isn't just an operational efficiency story — it sits directly inside the control set that regulators and auditors evaluate. SOX requires demonstrable controls over who can access financial systems and evidence that those controls operate consistently, which is exactly what a documented approval workflow and audit trail provide. HIPAA requires that access to protected health information be limited to what a role actually needs and revoked promptly when it's no longer justified — the mover and leaver stages, respectively. GDPR expects organizations to be able to demonstrate who had access to personal data and when that access was granted or removed, which is difficult to reconstruct from email threads and trivial to produce from an automated system's logs.

Every JML event handled through an automated workflow generates a timestamped record: who requested the change, who approved it, what the change was, and when it executed. That record is the audit trail auditors ask for directly, rather than something compliance teams have to reconstruct after the fact from scattered tickets and memory. It also protects the organization in the other direction — when a help desk technician or administrator makes a change, audit reports tied to their actions make it possible to review exactly what was done, closing off a common insider-risk blind spot in manually administered environments.

A real-world example

A 600-employee healthcare services company runs JML entirely through manual coordination: HR emails IT when someone joins or leaves, and role changes get handled whenever a manager happens to remember to ask. An internal audit ahead of a HIPAA compliance review turns up 14 accounts belonging to employees who left the company in the prior year, three of which still have active access to a system containing patient records. None of this was intentional negligence — it was the predictable result of offboarding depending on someone remembering to follow up across five different systems.

The company implements HCM-triggered automation: the HR platform becomes the trigger for every JML event, provisioning templates handle joiners consistently by role, and a leaver policy tied to "terminated" status in HR automatically removes group memberships, disables the account, and moves it to a departed-users OU the same day HR processes the exit. Movers — internal transfers between departments, which the audit had also flagged as a source of accumulated stale access — now trigger automatic permission reconciliation instead of relying on a manager's memory to request the change.

Approval workflows are configured so that access changes to systems holding patient data require a reviewer and approver beyond the original requester, satisfying the segregation-of-duties expectation the auditors specifically called out. Six months later, a follow-up review finds zero stale leaver accounts and a complete, timestamped record of every access change in the period — turning what had been the audit's single largest finding into a control the company can point to with confidence.

Common mistakes to avoid

• Automating joiners and leavers but leaving movers manual. Movers are the quietest source of entitlement creep because a role change often adds access without anyone thinking to remove what's no longer needed. If mover events aren't wired into the same automation as joiners and leavers, the JML model is only two-thirds implemented, and entitlement creep continues to accumulate through the gap.
• Skipping the approval workflow to move faster. Automation without requester-reviewer-approver-executor separation just makes mistakes happen faster and with less accountability. The workflow isn't friction for its own sake — it's the segregation-of-duties control that both security teams and auditors expect to see.
• Forgetting external users and contractors. If your automation is wired exclusively to the core HR system, anyone who exists outside it — contractors, partners, temporary staff — falls back into manual handling by default, quietly recreating the exact risk the automation was built to eliminate, just for a smaller population.

Frequently asked questions

Does JML automation require replacing our existing HR system?
No. JML automation platforms are designed to integrate with existing HCM systems via API or scheduled CSV import rather than replace them — the HR platform stays the system of record for employee data, and the identity platform reacts to changes in it.

What happens to a mover's old access if the automation only knows their new role?
Well-built mover automation works from modification templates that explicitly remove group memberships and permissions tied to the previous role at the same time it grants the new ones, rather than only adding access. This is precisely the gap that causes entitlement creep when handled manually, so it's worth confirming any automation tool you evaluate handles removal, not just addition.

Is same-day deprovisioning realistic, or is that an unreasonable bar?
It's realistic once deprovisioning is triggered directly by an HR status change rather than a manual handoff — the automation can execute within minutes of HR marking someone as terminated. The larger practical question is making sure HR actually updates that status promptly on the employee's last day, since the automation is only as fast as the trigger that starts it.

JML automation isn't a nice-to-have efficiency project — it's what turns identity management from a collection of error-prone manual tasks into a governed, auditable process that scales with the organization instead of falling further behind it every quarter. Get the joiners, movers, and leavers stages wired to a single source of truth with proper approval controls in place, and the stale-account problem that shows up in almost every first-time compliance audit simply stops accumulating.