Joiner-Mover-Leaver with your HR system: standard or custom?

Joiner-Mover-Leaver (JML) is the cycle of an employee who joins, changes role, and eventually leaves. "Connect your HR system and handle JML automatically" sounds like one button, but it sits at two levels. One level is standard, the other is custom work. This post explains the difference, so you know what to expect.

TL;DR

• JML sits at two levels: membership of groups and roles, and the creation and deletion of accounts.
• The membership level is standard: attributes decide groups and roles, and joiner, mover, and leaver follow on their own.
• Creating and deleting accounts from your HR system is custom work, not a standard button.
• We build that custom work with PowerShell in Azure Automation, runbooks on hybrid workers, that read the API of your HR system.
• The reason it is custom: every HR system has different fields and rules, so a one-size-fits-all would fit no one.

The two levels of JML

A lot of confusion about onboarding and offboarding comes from mixing two things:

1. The membership level. Which groups and roles a person should have, given who they are. This is about access.
2. The account level. Whether the account exists at all, and whether it is created, disabled, or deleted at the right moment. This is about the existence of the account itself.

A good JML process covers both. The difference is that the membership level can be captured in rules, and the account level depends on your specific HR system.

What is standard: the membership level

At the membership level, JML is simply a result of your attributes. ServiceChanger keeps group and role memberships correct based on the attributes already in your directory (the bucket model).

• Joiner. As soon as the account has the right attributes (department, job title, location), the rules pick up the standard access. No ticket needed.
• Mover. When someone's department or job title changes, the membership changes with them. What no longer fits falls away.
• Leaver. When the attributes fall away or the status changes, the rules pull the access back.

This is standard behavior. You define the logic once and the membership stays correct, even as people move.

What is custom: accounts from HR

Creating and deleting the account based on your HR system, that is, true onboarding and offboarding, is not a standard product button. The standard Access module does not create or delete accounts from an HR source. If you do want that, we build it as custom work on top of the same platform.

In practice:

• PowerShell scripts run in Azure Automation, in a runbook on hybrid workers.
• The scripts read the API of your HR system.
• Based on that, they perform actions on the local Active Directory and/or Entra ID: create, disable, or delete accounts, set attributes, and so on.

This uses the same hybrid architecture as the rest of ServiceChanger (runbooks on hybrid workers), so it sits alongside your Microsoft environment, not between it.

How the custom work works technically

The pattern is always the same: read the source, decide the action, perform it, and let the membership follow automatically.

# Runbook on a hybrid worker, runs on a schedule
1. Pull new and changed employees from the HR API
2. Joiner -> create account in AD/Entra ID, set department/title/location
3. Mover  -> update attributes (the rules adjust the membership)
4. Leaver -> disable account on the end date, delete after retention

Steps 2 to 4 only touch the account and its attributes. The groups and roles themselves you leave to the standard ABAC rules: as soon as the attributes are correct, the access is correct. That keeps the custom part small and the rest standard.

Why this is custom and not a standard feature

There is little useful to standardize at the account level. Every company has a different HR system, different fields, different rules, and different wishes for what should happen on a joiner, mover, or leaver. When may an account be created ahead of time? How long does it stay after a departure? Which field is leading for the department? A one-size-fits-all feature would fit no one well. So we deliver it as tailored work, on a platform that already does the rest as standard.

What to expect and what not

Scenario	Standard (membership)	Custom (account)
New employee	Rules grant the standard access	Create account from HR
Department change	Membership follows the new attribute	Update attribute from HR
Departure	Access falls away when attributes fall away	Disable account on the end date
Source of truth	Attributes in your directory	API of your HR system

The left column is standard. The right column we build as custom work when you want to drive the account level from HR too.

How ServiceChanger fits in

ServiceChanger applies group and role memberships across Entra ID and on-prem AD based on attributes (ABAC). That is the standard layer under the membership level of JML: you define the logic, and the membership is correct and stays correct.

By default ServiceChanger reacts to the attributes already in your directory; it does not create or delete accounts from an HR source on its own. If you want to connect your HR system for true onboarding and offboarding, we build that as custom work using automation accounts and runbooks in Azure. The License module tracks license usage based on Entra sign-in activity; the assignment of licenses itself stays with Microsoft. For AI-driven ticket handling there is ITSM Autopilot, our sister product.

FAQ

Does ServiceChanger do onboarding and offboarding from my HR system as standard? Not out of the box. The membership level (groups and roles) is standard. Creating and deleting accounts from HR we build as custom work with runbooks.

Why is that custom and not a button? Because every HR system has different fields and rules. There is no useful standard that is correct for everyone, so we deliver it tailored.

Does this work for on-prem Active Directory too? Yes. The runbooks run on hybrid workers and can perform actions on both on-prem AD and Entra ID, so a hybrid environment falls under one approach.

What stays manual? Decisions that need judgment, such as sensitive access with approval and exceptions that do not fit the pattern. Those belong with the service desk.

Further reading

• IT offboarding checklist: what you can automate for the steps of a full offboarding.
• Automating hybrid Active Directory with a PowerShell runbook for the runbook approach in detail.
• What is ABAC in Entra ID for the membership level under JML.

Next step

Want the membership level of JML to run as standard, with the account level added as custom work if needed? ServiceChanger automates group and role membership in Entra ID based on attributes. Book a demo or read the ABAC docs.