Joiner Mover Leaver Automation in Entra ID

Joiner mover leaver automation is the practice of keeping access correct as people join, change roles, and leave, without a help desk ticket for every step. For most mid-market Microsoft shops it is still a manual process: a joiner gets access from a checklist, a mover keeps old access nobody remembers to remove, and a leaver's account lingers with group memberships intact for weeks after their last day. None of this is because IT is careless. It is because the tooling to do it properly has, until recently, meant buying an enterprise identity governance suite built for organizations ten times your size.

That gap is closing. If your identity platform is Entra ID and on-prem Active Directory, you already have the raw material for full JML automation: user attributes, dynamic groups, and role assignments. What is usually missing is the layer that turns attribute changes into access changes automatically and keeps a record of why. This article walks through how that works in practice, and where the line sits between what you can automate out of the box and what still needs care.

Why JML breaks down in practice

Most IT teams do not lack a JML process on paper. They lack one that survives contact with reality.

The joiner problem: slow, inconsistent starts

New hires wait on tickets for access that should have been obvious the moment their department and job title were set. Every joiner ends up with a slightly different starting point, because the person provisioning access on day one made slightly different judgment calls than the person who did it for the last hire in that role.

The mover problem: access that never shrinks

Movers are the quiet failure mode. Someone changes teams and gets the new access added, but the old access is rarely revoked, because removing something feels riskier than leaving it. Over a few years, employees who have moved departments twice accumulate a footprint that reflects their entire career, not their current job.

The leaver problem: standing access after departure

Leavers are the highest-risk case. Between an employee's last working day and the moment every group membership, app role, and license is actually cleaned up, there is often a window measured in days or weeks, not minutes. That window is exactly where audits and security incidents tend to land.

The two layers of JML you need to separate

A lot of confusion about "automating JML" comes from treating it as one problem. It is really two, and they need different solutions.

1. The access layer. Which groups, roles, and app assignments a person should have, based on who they are today. This is what determines what a joiner, mover, or leaver can actually reach.
2. The account layer. Whether the account itself exists, is enabled, and holds the right attributes in the first place. This is where the account is created, disabled, or deleted.

The access layer can be fully standardized with attribute-based rules. The account layer depends on your specific HR system, your approval process, and company-specific timing rules, so it is closer to a custom integration than a one-size-fits-all feature.

Automating the access layer with ABAC

The practical way to automate the access layer in Entra ID and on-prem AD is attribute-based access control (ABAC). Instead of manually placing a user into a group, you define a rule that describes who belongs, and the platform keeps membership correct as attributes change.

How it plays out for each JML event

• Joiner. As soon as the account carries the right attributes (department, job title, location, employment type), the rules assign the standard groups and roles. No ticket required for the baseline access.
• Mover. When a department or job title changes in the directory, membership updates with it. Access tied to the old attribute set falls away, access tied to the new one is picked up.
• Leaver. When the status attribute changes (or the account is disabled), the rules pull group and role membership back automatically, rather than leaving it in place until someone remembers to clean it up.

This is exactly what ServiceChanger's ABAC engine does: it applies group and role membership across Entra ID and on-prem Active Directory based on the attributes already in your directory, so joiner, mover, and leaver events on the access side happen automatically, without hand-editing group membership.

Where group mining helps you start

Most teams do not start from a blank slate. Group mining looks at your existing group structure and usage patterns and suggests rule definitions that match how access is already organized, so you are not reverse-engineering years of manual group management by hand before you can automate anything.

What still needs to be built for the account layer

Creating and deleting accounts based on your HR system, true onboarding and offboarding at the account level, is not something a generic product feature does well for every company. Every HR system has different fields, different approval steps, and different rules about timing (when can an account be pre-created, how long does it stay after departure, which field is authoritative for department).

Where that connection is needed, it is typically built as automation on top of the same Microsoft platform:

# Runbook on a hybrid worker, triggered on a schedule
1. Pull new and changed employee records from the HR API
2. Joiner -> create the account, set department/title/location
3. Mover  -> update the changed attributes
4. Leaver -> disable the account on the end date, delete after retention

Notice that steps 2 through 4 only touch the account and its attributes. The moment those attributes are correct, the ABAC rules take over and adjust group and role membership on their own. That division keeps the custom part small and the standardized part doing most of the work.

Standard versus custom, at a glance

JML event	Access layer (standard, attribute-driven)	Account layer (built per HR system)
Joiner	Rules assign baseline groups and roles	Account created from HR record
Mover	Membership follows the updated attribute	Attribute updated from HR
Leaver	Access is withdrawn when the attribute changes	Account disabled/deleted on schedule
Source of truth	Attributes already in the directory	The HR system's API

A practical rollout order

1. Start with the access layer. Identify the group memberships that consume the most manual effort today, usually department-wide access and standard app roles.
2. Check attribute quality for that population. Inconsistent job titles or missing department values will quietly break your rules.
3. Write the membership rules and run them alongside existing manual assignments for a few weeks before removing the manual step.
4. Only once the access layer is stable, decide whether you need account-level automation from your HR system, and scope that as its own project.

Doing it in this order means you get the highest-value part, correct access through moves and departures, without waiting on an HR integration project to finish first.

FAQ

What is joiner mover leaver automation exactly? It is the automatic adjustment of a person's access, group memberships, and roles as they join a company, change jobs internally, or leave, driven by attribute changes rather than manual tickets.

Do I need an enterprise IGA suite to automate JML? Not for the access layer. If your directory is Entra ID and on-prem Active Directory, attribute-based access control can automate group and role membership for joiners, movers, and leavers without the cost and complexity of a full enterprise governance platform.

Does ServiceChanger create or delete user accounts from my HR system? Not as a standard feature. ServiceChanger's ABAC engine automates group and role membership based on the attributes already in your directory. Connecting an HR source for true account creation and deletion is typically built as custom automation using Azure automation accounts and runbooks.

Does this work in a hybrid environment with on-prem AD? Yes. The access layer applies to both Entra ID and on-prem Active Directory, so a hybrid environment is covered under one model rather than two separate processes.

Further reading

Automating access on the JML side of the lifecycle starts with getting the underlying access model right. For the full picture of how identity and access management fits together, see our identity and access management (IAM) guide. For more on the rule engine that powers this automation, browse our articles tagged Entra ID and Automation.

Next step

Want joiner, mover, and leaver access to stay correct automatically, without rebuilding your identity platform? ServiceChanger automates group and role membership in Entra ID and on-prem Active Directory based on the attributes you already have. Book a demo to see how it fits your environment.