Every access decision your organization makes traces back to one of three events — someone joined, someone moved, or someone left. Here's how to govern all three without leaving gaps.
For IT teams, JML is a volume and consistency problem. New hires arrive faster than manual provisioning can keep up. Role changes create a constant stream of access updates, half of which never get completed. Departures leave a trail of active accounts that nobody is tracking. The overhead compounds with every hire, every promotion, every departure.
For employees (and for vendors, contractors, consultants, and partners who also need access to do their work), JML is a productivity and experience problem. Waiting days for tools on your first day. Not knowing the status of an access request. Being added to the wrong channels, or not being added at all. Having access that doesn't match your current role. Each of these is a friction point that costs time and erodes trust in IT.
Joiners, movers, and leavers (JML) is the framework that governs how IT teams manage access across every lifecycle event — for all identities, not just full-time employees. Get it right and IT runs on automation, users get timely access, and security and compliance are byproducts of a process that just works.
This guide covers what JML means, how each phase works, where it breaks down without automation, and how to build a process that handles all three reliably at scale.
What Are Joiners, Movers, and Leavers?
JML stands for Joiners, Movers, and Leavers, the three primary lifecycle events that require access management decisions for every employee in your organization.
Joiners are new employees entering the organization. They need the right applications, licenses, and permissions provisioned before they start — based on their role, department, seniority, and location.
Movers are existing employees who undergo an internal transition — a promotion, department transfer, role change, or location move. They need their access adjusted: old-role tools removed, new-role tools added, with permission levels recalculated to match the new position.
Leavers are employees who exit the organization — by resignation, termination, retirement, or any other separation. All access needs to be revoked, accounts deactivated, data backed up and reassigned, and the full deprovisioning sequence completed before or on their last day.
These three events happen continuously in any growing organization. How reliably you handle each one determines your access posture, the gap between who should have access to what, and who actually does.
Why JML Matters — For IT Teams and for Users
For IT teams, JML is an operational efficiency problem. Every lifecycle event — a new joiner, a role change, a departure — creates manual work. Coordinating with HR to find out about new hires. Figuring out what access a new role requires. Chasing down which apps a departing employee has. Updating two systems when one field changes in the HRMS. Without automation, this work never ends and never scales.
For users — employees, contractors, vendors, partners — JML is a productivity and experience problem. A new employee who doesn't have their tools on day one loses their first day to chasing IT. A contractor who can't access the project system can't contribute. A promoted employee whose access doesn't reflect their new role hits friction immediately. A vendor whose engagement ended but whose credentials are still active is an unresolved loose end for both parties.
The compounding effect is what makes JML worth getting right. Incomplete joiner provisioning creates workarounds. Incomplete mover handling creates access accumulation. Incomplete leaver processes create persistent exposure. Each failure is manageable on its own. Together, across hundreds of employees and external users over months and years, they produce an access environment where nobody is quite sure who has what — and neither is IT.
The Three Phases of JML — How Each One Works
Joiners: Provisioning Access from Day One
When a new employee joins, the clock starts before they arrive. By the time they sit down on their first day, they should have access to every application their role requires, not because someone filed a ticket in time, but because the provisioning happened automatically when their HR record was created.
What triggers joiner provisioning
The signal is the new hire record in your HRMS: Workday, BambooHR, HiBob, Zoho Recruit, or whichever system HR uses to record new employees. When that record is created, it carries the attributes that determine what access the employee needs: role, department, seniority, location, employment type.
A well-built JML process watches for that record and fires provisioning automatically. No ticket required. No IT admin manually interpreting a "please set up the new marketing analyst" request and deciding which applications that means.
Birthright access, the baseline every joiner gets
Birthright access is the standard entitlement for a role: the applications and permissions every employee in that role, department, and seniority level receives on day one. A software engineer gets their IDE, version control access, ticketing system, and communication tools. A sales analyst gets the CRM, reporting dashboards, communication tools, and relevant data sources.
Birthright access is role-defined, not individually requested. It runs automatically, at scale, without configuration per person — only per role.
Contextual recommendations beyond the baseline
Beyond birthright access, contextual app recommendations surface additional tools based on what peers in the same role, department, and seniority level actually use. These recommendations come from live usage data, not a manually maintained list. A new content writer joining marketing sees ProWritingAid, Grammarly, and Trello suggested because that's what the rest of the content team is actively using.
The same intelligence applies to in-app setup. Rather than just provisioning Slack, the system recommends which channels, groups, and projects to add the new employee to, based on what their peers are already part of. The employee doesn't spend their first week asking colleagues which channels to join — they arrive already there.
This also means provisioning can happen before the start date. Identity creation a week before, channel access a couple of days before, full application access on day one. The employee's first-day experience reflects a team that prepared for them.
In-app suggestions for team integration
Application access is only part of day-one provisioning. Employees also need to be added to the right Slack channels, assigned to the right project boards, and included in the right email groups. These in-app suggestions — adding the new software engineer to the engineering Slack channels, the product board, the relevant GitHub repositories — are part of a complete onboarding Playbook, not an afterthought.
What Zluri does here: When a new hire record appears in the connected HRMS, Zluri surfaces contextual app recommendations based on department, role, and seniority, and fires the appropriate onboarding Playbook automatically. Playbooks are reusable workflow templates — configured once per role profile and applied to every employee in that role without manual setup per hire. For BambooHR, Google Workspace, Azure AD, and Okta, the sync is instant. For other HRMS integrations, it runs on a 24-hour cycle. The "Recent Runs" tab gives IT full visibility into whether each onboarding run completed, failed, or is pending, without manual follow-up.
Movers: Handling Internal Transitions Without Accumulating Access Debt
Movers are the hardest phase of JML to manage consistently, not because the events are complex, but because they happen continuously, the removal side is never urgent, and the accumulation is invisible until you go looking for it.
Two types of mover events
Mover events split into two categories that require different handling:
HRMS-triggered transitions have a signal — a field change in your HR system. A designation change (promotion, role change), a department change (transfer), a reporting manager change (reorg), or a location change (relocation) all update fields in the HRMS. The gap is that nothing typically acts on that signal automatically. Someone in IT might notice, or a ticket might arrive eventually. The removal of old-role access almost certainly won't happen at the same moment as the addition of new-role access.
Event-based transitions have no HRMS signal at all. A developer added to a Slack channel for a product launch. An analyst given temporary dashboard access during a data migration. An employee covering for a colleague on leave. These are informal grants — often correct and legitimate, with no defined end. They persist because nobody has a mechanism to find them and nobody filed a removal request.
The access creep problem
Access creep is what happens when additions accumulate and removals don't keep pace. An employee who joined as a junior marketer, moved to product after two years, and got promoted to a senior role is now holding access that spans three roles — each layer left in place because removal wasn't urgent at the time of transition.
From an attacker's perspective, an overprivileged identity is a high-value target: it can move laterally across systems that a correctly-provisioned identity in the same role couldn't reach. From a compliance perspective, it's a control failure — least privilege isn't enforced if access from previous roles persists indefinitely.
How automation handles HRMS-triggered movers
When a designation or department field changes in the HRMS, an automation rule fires. That rule follows a three-part structure:
The trigger is the field change: department changes, designation changes, reporting manager changes, status changes, location changes.
The conditions check user attributes to determine which playbooks apply: employment type, current department, current designation, previous department. This is what allows a single rule to branch correctly — a contractor promotion gets a different playbook than a full-time promotion.
The action chains a deprovisioning playbook (removing old-role access) into a "Trigger Playbook" action that runs the onboarding playbook for the new role — both halves of the transition in one rule, in sequence, rather than two separately-timed tickets.
A configurable "Wait For" delay between the two sides allows a handoff window: the employee retains old-department access for a defined period while they close out open work or brief successors. The delay is explicit and bounded, not indefinite.
Granular permission levels, not just application presence
The depth of mover automation matters. "Still has GitHub" looks correct from the outside. "Has the right level of GitHub for their current designation" is the actual security outcome.
Permission-level granularity grants not just access to an application, but the correct scope within it, calculated from the user's current designation at execution time. A Software Engineer gets Triage-level access to specific repositories. An Engineering Manager gets Admin-level access to the organization plus additional repositories their team owns. When that Software Engineer is promoted to Engineering Manager, the automation doesn't confirm "GitHub continues", it recalculates the scope and applies the new level automatically.
How automation handles event-based movers
Event-based access needs a structured channel and a built-in expiry. Without both, it accumulates alongside HRMS-triggered access and is equally invisible at audit time.
A self-service access request model handles this: the employee submits a structured request with a business justification, it routes to the appropriate approver, and the approval includes an access duration setting. Time-bound access expires automatically on the set date, the ending is designed into the grant at the moment it's made, not hoped for afterward.
What Zluri does here: Zluri's Automation Rules watch for HRMS field changes and fire the correct playbooks (deprovisioning old-role access and provisioning new-role access in a single chained rule, with a configurable Wait For delay for handoff periods. Apply Condition sets the correct permission scope within each application at execution time. For event-based movers, Access Requests (also known as the Employee App Store) provides a structured request channel with time-bound access duration and automatic expiry. The Changelogs tab records every approval modification, keeping a clean audit trail for every access decision made outside standard provisioning.
Leavers: Deprovisioning Every Access Point Before the Door Closes
Leavers are the phase with the highest consequence for getting it wrong. A delayed onboarding slows one employee's productivity for a week. A missed deprovisioning leaves active credentials with someone who no longer works for your organization, and that exposure doesn't resolve on its own.
The completeness problem
Most IT teams have reliable offboarding coverage for centrally-managed applications: SSO-connected tools, core SaaS platforms, anything that went through official procurement. The exposure comes from everything outside that perimeter: applications provisioned by department managers, tools employees signed up for using their work email, SaaS trials that became permanent without IT involvement.
A manual offboarding checklist covers what IT knows about. For an employee who has been at the organization for three years and moved through two departments, the gap between "what's on the checklist" and "what the employee actually has access to" can be substantial.
The timing problem
Offboarding needs to happen on time: on the last day for planned departures, immediately for involuntary separations. A manual process depends on a ticket being filed, prioritized, and worked before credentials need to be revoked. In practice, there's almost always a gap. For involuntary terminations, that gap is measured in hours. For resignations with notice periods, the ticket can sit until someone notices it hasn't been closed.
The data handling requirement
Deprovisioning isn't only access revocation. Before licenses are terminated, the departing employee's data needs to be backed up and made available for transfer to a successor. After deprovisioning, account deletion should cover both application-level access and cloud data, not just the login credentials.
A complete offboarding sequence: access revoked from all devices and applications → data backed up and stored → user license revoked → SSO removed → account deleted including cloud data.
JML policy for leavers
A JML leaver policy defines what "complete" offboarding means: which applications require same-day revocation, what the data backup and reassignment process covers, how involuntary separations are handled differently from planned ones, and who owns the offboarding workflow for each department. Without a defined policy, completeness depends on whoever handles the ticket that day. With a policy encoded into automated playbooks, every departure follows the same sequence.
What Zluri does here: When an offboarding workflow is created for a departing employee, Zluri automatically scans their full access footprint and pre-populates the workflow with every application they have access to, including shadow IT, with suggested deprovisioning actions per app. IT doesn't need to recall every tool the employee used; Zluri surfaces it. The workflow covers access revocation, device retrieval (via integrations like Jamf Pro), data backup before license termination, and full account deletion including cloud data. After deprovisioning, Zluri restores data and deletes the ex-employee's account covering both app and cloud data. Offboarding runs can be scheduled to execute on the exit date or triggered immediately for urgent separations.
What a Complete JML Process Looks Like
A mature JML process has five components working together:
1. A reliable system of record
Everything starts with clean data in the HRMS. Stale designations, missing department assignments, or active records for former employees produce incorrect provisioning decisions downstream. Before automating JML, verify data quality in your source of truth.
2. Connected directories and identity providers
The HRMS needs real-time connections to the systems that govern access: Active Directory, your identity provider (Okta, Azure AD, Google Workspace, Ping Identity), and your application stack. Changes in the HRMS propagate into access changes without manual intervention between them.
3. Role-based access profiles
For each role, department, and seniority level, define what standard access looks like. This is your birthright access matrix, the baseline that onboarding playbooks execute, and the benchmark against which you identify excess access during reviews.
4. Reusable playbooks per role
Build onboarding and offboarding playbooks for each role profile. The same playbook runs for every new software engineer, every departing marketing manager, every employee transferring from Sales to Customer Success. Configuration happens once per role, not once per person.
5. Automation rules tied to HRMS triggers
Connect playbooks to HRMS events so they fire automatically: new hire record fires the onboarding playbook, designation change fires the mover playbooks, exit date fires the offboarding playbook. This is the difference between JML as a checklist (someone has to run it) and JML as a process (it runs when the condition is met).
Common JML Failure Modes
Access that outlives the reason for it
The most common failure: access granted for a legitimate reason that persists after the reason expires. A developer's elevated permissions from a production incident. A marketer's CRM access during a joint sales campaign. An employee's tools from a former department. Without a defined expiry at the point of grant, these become permanent by default.
The HR-IT coordination gap
In a manual JML process, HR and IT operate on separate systems with no live connection. A new hire record gets created in the HRMS. IT waits for someone to tell them — via email, Slack, a spreadsheet, or a ticket. The same fragmented handoff happens for every role change and every departure. Two employees hired into the same role on the same week can end up with different access profiles simply because different people handled their tickets. Automation replaces the handoff with a direct system-to-system connection: HR updates the record, the system acts on it.
The "ticket not filed" gap
Manual JML depends on someone filing a ticket. During high-volume periods (large onboarding cohorts, restructurings, year-end attrition) — tickets don't always get filed on time, and don't always get worked promptly. Automated JML fires on the event regardless of ticket volume.
HRMS and directory drift
When HRMS records and directory records diverge (a department updated in one but not the other), access decisions downstream are made on stale data. Keeping the source of truth clean and connected is a prerequisite for reliable JML automation.
Shadow IT at offboarding
An offboarding process that covers only centrally-managed applications is incomplete by definition. Full offboarding coverage requires visibility into the complete access footprint, not just the known list.
Approvals without expiry
Access requests that go through a proper approval process but have no defined duration are a primary source of event-based access accumulation. The approval happened correctly. The problem is that approval without an end date is a permanent grant by default. JML automation for event-based access requires that duration is set at the time of approval.
How Zluri Automates JML End to End
Zluri is an identity security platform built to automate the complete JML lifecycle across the full employee and application stack.
For Joiners, Zluri connects to your HRMS and fires role-specific onboarding Playbooks automatically when new hire records appear. Recommendations are driven by peer group analysis — Zluri knows what tools each team, department, and seniority level actually uses, so the suggested stack reflects real usage. In-app suggestions handle channel, group, and repository assignments within each provisioned application. Playbooks can be staged to run before the start date: identity creation ahead of time, full access on day one. Configured once per role profile, the same Playbook runs for every hire in that role. Instant sync for BambooHR, Google Workspace, Azure AD, and Okta means provisioning fires the moment the HR record is created.
For Movers, Automation Rules watch for HRMS field changes and execute deprovisioning and provisioning playbooks in a single chained rule, with a configurable Wait For delay for handoff windows. Apply Condition sets the correct permission scope within each application based on the user's current designation at execution time. The Employee App Store handles event-based access requests with time-bound duration and automatic expiry, so every informal grant has a defined ending.
For Leavers, Zluri auto-populates the offboarding workflow by scanning the departing employee's complete access footprint, including shadow IT, and pre-filling every application with suggested deprovisioning actions. The workflow covers access revocation across all devices, data backup before license termination, device retrieval where integrated, and full account and cloud data deletion. Runs can be scheduled for the exit date or triggered immediately for urgent separations. The Scheduled Run timestamp is direct compliance proof that access ended at exit, not days later.
Across all three phases, Zluri maintains a complete audit trail: every action logged with timestamp, executor, and outcome. Run Logs show playbook status — completed, completed with errors, failed, or pending. Onboarding Scheduled Runs prove access started only from the hire date; offboarding Scheduled Runs prove access ended at exit. Both can be exported automatically on a recurring schedule to compliance teams. Reports for SOC 2, ISO 27001, HIPAA, SOX, and GDPR are generated directly from this data — no reconstruction from email chains. Zluri connects to 300+ integrations across directories, SSOs, and HRMS platforms, covering human and non-human identities across the full application stack.
For external users — vendors, contractors, and partners — who have no HRMS record and therefore no automatic lifecycle trigger, Access Requests (also known as the Employee App Store) provides the governance mechanism: every access grant carries a time-bound expiry set at approval, and a separate Contractor offboarding Playbook handles their deprovisioning distinct from the standard employee exit flow. A single conditional Playbook can also handle both employee and contractor onboarding with branching logic: FTEs get added to all team channels while contractors get access only to relevant project groups, without maintaining two separate Playbooks. Approvers reviewing these requests get contextual intelligence — peer adoption rates, the requester's request history, and whether the access level is standard or privileged — so decisions are informed rather than blind.
Frequently Asked Questions
What does JML stand for?
JML stands for Joiners, Movers, and Leavers, the three primary lifecycle events that require access management decisions for every employee. Joiners are new employees who need access provisioned. Movers are employees undergoing internal transitions who need access adjusted. Leavers are employees exiting the organization who need all access revoked.
What is a JML process?
A JML process is the set of policies, workflows, and automation rules that govern how access is provisioned, adjusted, and revoked at each phase of the employee lifecycle. A mature JML process connects the HRMS to access management systems so that lifecycle events automatically trigger the correct provisioning or deprovisioning actions, without manual tickets for standard cases.
What is a JML policy?
A JML policy is the documented ruleset that defines what access management should look like at each lifecycle phase: what constitutes birthright access for each role, which HRMS events trigger automated access changes, what the removal policy is for old-role access during transitions, and what complete offboarding looks like per application category. The policy is what automation encodes. Decisions made in advance so individual cases don't require individual decisions each time.
What is JML automation?
JML automation uses HRMS integrations, automation rules, and workflow playbooks to handle provisioning and deprovisioning automatically, triggered by lifecycle events rather than manual tickets. When a new hire record is created, an onboarding playbook fires. When a department field changes, deprovisioning and onboarding playbooks execute in sequence. When an exit date arrives, the offboarding playbook runs automatically.
What is the difference between JML and IAM?
Identity and Access Management (IAM) is the broader discipline of managing digital identities and their access to systems. JML is the lifecycle-specific component of IAM — the framework that governs how access changes in response to employee lifecycle events. JML is how IAM is operationalized across the employee journey.
Why is the mover phase the hardest to manage?
Movers are the hardest phase because the failure mode is invisible. When a joiner isn't provisioned, they can't work, the problem surfaces immediately. When a leaver isn't deprovisioned, there's an active credential exposure. When a mover's old access isn't removed, nothing breaks. Nobody is blocked. The accumulation is silent, compounding across every role change until the employee holds access far beyond their current role warrants. This silence is what makes manual mover handling structurally unreliable.
How does JML relate to the principle of least privilege?
The principle of least privilege states that users should have only the minimum access necessary for their current role. JML is how least privilege is maintained over time. Without consistent mover handling, least privilege erodes with each role transition: access is added for the new role but old access isn't removed, and effective permissions expand beyond what any single role warrants. Automated JML enforces least privilege dynamically: access is recalculated at each transition, not accumulated.
What is the risk of poor leaver management?
Active credentials belonging to former employees are one of the most common vectors for unauthorized access. The risk is highest immediately following separation, particularly for involuntary terminations where the employee is aware of their departure before IT completes deprovisioning. Shadow IT and department-managed tools are the most likely gaps in manual offboarding. A complete leaver process requires visibility into the full access footprint, not just the applications IT centrally manages.
.svg)
