Every joiner gets a checklist. Every leaver gets a process. Every mover gets a Slack message.
Ask any IT or security team where their lifecycle automation is strongest and you'll hear the same two answers: onboarding and offboarding.
A new hire comes in, there's a checklist. Someone leaves, there's a process.
Both events have clear ownership, tooling built around them, and at least some form of playbook, however mature.
Then ask about everything in between.
A promotion. A department transfer. Someone moving to a new location. A six-month project that pulls someone into a cross-functional team. A parental leave and the coverage access someone else picks up while they're gone.
These are mover events, and most organizations handle them with a Slack message, a manual ticket, or a quiet hope that someone remembers to follow up.
This isn't a people problem. It's a structural one. And it's why movers are the orphan child of identity management — the lifecycle event that tools, vendors, and security teams have largely left behind.
Why joiners and leavers get all the attention
Onboarding and offboarding are tractable problems. Not easy, but tractable. Each has a clear trigger, a clear direction, and a clear end state.
A joiner's target state is simple: give them access to everything their role calls for. Apply it on day one, verify it's complete, done.
A leaver's target state is simpler: zero. Remove everything, everywhere, with no exceptions. The hard part is making sure "everywhere" actually means everywhere (SSO, OAuth grants, shared credentials, API tokens) — but the destination is never in question.
Both events also carry organizational urgency. A new hire who can't access their tools on day one is a visible problem with a visible owner. An employee exit with open access is a risk compliance and security teams actively track.
This combination — clear process, clear trigger, real pressure — is why onboarding and offboarding get investment. They're the events that are easy to define, easy to audit, and hard to ignore when they go wrong.
Why movers are different
A mover event has none of these properties.
No visibility into existing access.
Most teams don't actually know what access someone has. Not what the HR system says they should have — what they actually hold across every app, every OAuth grant, every shared credential.
Without that picture, you can't compute a delta. You can't say "remove these, keep these, add these." So teams do what they can: provision the obvious new access and leave everything else in place.
No trigger most tools respond to.
Even when something fires — an HRMS field changes, a new title appears — most access management tooling has no workflow configured for it. Joiners and leavers have dedicated flows. A department transfer fires a notification that someone has to act on manually, if they notice it at all.
The result: access changes that depend entirely on a person remembering, at the right moment, to do the right thing.
No organizational urgency.
A joiner blocked without access creates immediate pressure. A mover who gets only the basics of their new role — and Slacks their manager for everything else — creates friction, not crisis.
The path of least resistance: provision the obvious new access, leave the old access in place, handle the rest through ad hoc requests. This is exactly what happens at most organizations. Which is exactly why mover access accumulates quietly for years.
Every internal move adds a little access and removes almost nothing. An employee who's made three internal moves over five years may hold the access footprint of a partial IT administrator — not because anyone granted that deliberately, but because nothing was ever systematically removed.
Why most tools ignore movers too
It's not just internal teams. IGA vendors and access management platforms have historically focused their lifecycle automation on joiners and leavers — cleaner to model, cleaner to implement, cleaner to sell.
Joiners and leavers map to a simple on/off state. Movers don't.
Automating a mover event correctly requires:
- Real-time visibility into what the person actually holds, not just what their role profile says they should have
- Logic for what carries forward, what gets removed, and what changes in scope — not just what gets added
- A trigger architecture that handles multiple simultaneous HR changes without creating conflicting playbooks
That's a substantially harder problem than "on day one, apply role profile" or "on exit date, remove everything." Which is why most platforms still treat moves as a manual process, or at best a limited set of pre-built role-change templates that don't account for real-world complexity.
Two types of mover events and why the distinction matters
Not all mover access has the same character. Two structurally different categories emerge — and they require two structurally different solutions.
Scheduled-based changes: the HRMS knows
These are events the HR system records the moment they happen. The signal exists. The problem is nothing acts on it automatically.
Promotions carry title and level changes — usually accompanied by different permission levels within existing tools, not just different apps, but different scope within the same apps.
Role changes shift someone's function entirely, triggering a new access profile that may bear little resemblance to the old one.
Department changes are the most complex: simultaneous removal of old-department tooling and addition of new-department tooling, with a brief overlap window that creates segregation-of-duties exposure if not managed deliberately.
Team changes are lower-profile but no less real — resource-level access (repositories, channels, shared drives) shifts even when the employee never formally changes department.
Location changes carry compliance and data-residency implications that go well beyond updating an address in an HR record.
Long-term leaves (maternity, paternity, medical) have a known start date, a theoretical return date, and a coverage gap in between where someone else's temporary access needs to be provisioned and eventually cleaned up.
Each of these shares one thing: the HR system knows it happened. The trigger exists. The gap is that nothing is listening.
Event-based changes: invisible endings
Unlike scheduled changes, these access grants are invisible to the HRMS from the start.
No field change records them. No system is notified when they're created. The only person who knows the access exists — and why — is the person who asked for it. That makes the HRMS useless as a trigger, and Access Requests the only viable mechanism for managing them.
Project access is scoped to an initiative that will eventually conclude — but project completion is not an event any access management system natively tracks.
Cross-functional collaboration grants access for an ongoing working relationship with no project boundary and no natural end date at all.
Temporary elevated access (permissions granted during an incident, an on-call window, a maintenance task) depends on post-event follow-through that rarely happens with any consistency.
Urgent and emergency access is the sharpest case: access is granted first, approval follows retroactively, and retrospective audits are the first thing to get deprioritized when the next incident arrives.
Coverage and backup access has an obvious natural expiry (the absent person's return) — but most systems can't express "expires when X comes back" as a condition, so it persists on an arbitrary date or not at all.
Learning and exploration access has no deliverable, no project, no signal for done.
What all six have in common: the HR system never knew they existed. No trigger will ever fire to clean them up unless the ending was designed into the grant from the start.
Why it's worth taking seriously
The instinct is to treat mover access as an inconvenience rather than a risk. No breach investigation leads with "stale project access from a department transfer two years ago."
But that's precisely where privilege creep compounds.
Not a single dramatic failure — but the quiet accumulation of individually justified, once-appropriate grants that nobody ever revisited. When that footprint gets surfaced (in a compliance audit, a pen test, an incident investigation) the question is always: how?
The answer is never dramatic. Access management tooling drew a line at joiners and leavers, and everything in between just stacked up.
How Zluri approaches the mover problem
The reason movers are hard isn't that organizations don't care. It's that solving them requires two things most platforms don't provide together: visibility into what someone actually holds, and automation that responds to the right signals for both categories of mover event.
For scheduled-based changes, Zluri's Access Management module uses HRMS-triggered automation rules. Every rule follows a three-part structure: a trigger, conditions that determine whether it applies, and playbooks that execute the actual access changes.
When a field changes in the HR system (designation, department, location, leave status) an automation rule fires and executes the appropriate playbook — deprovisioning what the old role required and provisioning what the new role requires, at the right permission levels, in the right sequence.
For BambooHR, Google Workspace, Azure AD, and Okta, this happens on instant sync. No ticket raised. No human remembering to act. The HR record is the trigger.
For event-based changes, the mechanism is different because the signal is different — there is no HRMS field change to listen to.
The only person who knows this access exists is the person who requested it. Zluri's Access Requests module handles this through a structured request flow: the employee submits a request with a business justification, it routes to the right approver automatically, and once approved, provisioning runs via an AppPlaybook (automated) or a Task assigned to a designated owner (manual, for apps without a direct integration).
The critical governance layer is the Access Duration field. Requests can be permanent or time-bound. When set as time-bound, the access expires on that date without requiring a separate removal request — forcing the conversation about duration to happen at grant time, not months later during an access review.
What connects both approaches is visibility. Before either automation can work correctly, you need to know what someone actually holds across every application, every permission level, every grant type — not just what their role profile implies they should have.
Automation that fires on incomplete or stale access data doesn't solve the mover problem. It just executes the wrong playbook faster.
Frequently Asked Questions
What is a mover event in identity management?
A mover event is any mid-lifecycle change to an employee's role, team, location, or access needs — promotions, department transfers, long-term leaves, temporary project access, and more. Unlike joiners and leavers, mover events don't have a clear target state or organizational urgency attached, which is why they're the most under-automated part of the JML lifecycle.
Why is mover access harder to manage than joiner or leaver access?
Joiners and leavers have a defined destination — full role access or zero access. A mover's destination depends on a role-to-access mapping most organizations haven't formally defined, and on visibility into what the person currently holds, which most tools don't provide. Without both, you can't compute what to add, remove, or carry forward.
What's the difference between scheduled-based and event-based mover changes?
Scheduled-based changes (promotions, department transfers, location changes, long-term leaves) are recorded in the HR system — the trigger exists, but most tools don't act on it. Event-based changes (project access, temporary elevated permissions, emergency access, coverage grants) are invisible to the HRMS entirely — the only person who knows the access exists is the person who requested it, which makes Access Requests with time-bound grants the only viable governance mechanism.
What is privilege creep and how do mover events cause it?
Privilege creep is the gradual accumulation of access rights beyond what a person's current role requires. Mover events are the primary driver: each internal move adds new access and rarely removes old access, so an employee who's changed roles three times may hold permissions from every position they've ever had. Over years, this creates an access footprint that bears no relationship to the person's actual job.
How does Zluri handle mover events?
Zluri addresses the two categories separately. For scheduled-based changes, the Access Management module uses HRMS-triggered automation rules — when a designation, department, or status field changes, a playbook fires that handles both deprovisioning and provisioning in sequence. For event-based changes, the Access Requests module enforces time-bound grants with an Access Duration field set at the moment of approval, so temporary access expires automatically rather than persisting indefinitely.
.svg)
