What a joiner-mover-leaver process actually automates

“JML” sounds like three equivalent cases. In implementation they are three very different problems, and only one of them is genuinely hard.

Joiner: the solved problem

Onboarding is the case almost every organisation has under control, because it is immediately obvious when it fails. Somebody sits there on their first day and cannot get in: that escalates by itself.

• —Create the account, with a naming scheme that still works for the second Schmidt
• —Set attributes: department, manager, job title, location, the later basis for every dynamic group
• —Derive group memberships from the role instead of assigning them individually
• —Assign a licence, ideally group-based rather than direct
• —Issue initial credentials without sending a password over an unsecured channel

The only real decision here is how much you assign directly and how much follows from group membership. Everything assigned directly has to be collected back individually later. Everything attached to a group disappears when the membership ends. That decision determines how hard the leaver becomes.

Mover: the underestimated problem

A move is the case where something breaks quietly. Somebody transfers from sales to accounting, receives the new permissions and keeps the old ones. Nothing breaks, nobody complains, and that is exactly why it goes unnoticed.

Technically a move is not one change but two: a grant and a revoke. Almost always only the first half gets automated. After three moves in five years, one person holds the access rights of four departments. In the access review that then shows up as “grown organically”. In fact it was simply never cleaned up.

The cleanest lever against this is to stop managing memberships and start deriving them. If a dynamic group filters on department, a single attribute change does both halves: the old membership ends, the new one begins. The prerequisite, of course, is that the attribute is actually maintained, and that it is clear which system owns it.

Leaver: the problem that breaks

Offboarding is what breaks most often in practice, for an unspectacular reason: the trigger is missing. Onboarding has a date on which somebody stands at the door. Offboarding has a date in a system that does not talk to IT.

The rest is a sequence you define once and then keep to:

1. 1.Disable the account, the fast and reversible step
2. 2.Revoke active sessions, otherwise existing tokens keep working
3. 3.Remove group memberships and reclaim licences
4. 4.Hand over the mailbox and files before anything is deleted
5. 5.Check owner roles: orphaned groups, apps and teams
6. 6.Delete, considerably later than it feels right to

Two of those are the ones regularly missing from scripts. The first: disabling does not end a session. An issued refresh token stays valid until it expires. The account is locked, the access continues.

The second: ownership. If the only owner of a group leaves, that group no longer has anybody to administer it. You notice months later, when somebody wants to change a membership and there is nobody who is allowed to.

What I took away from it

When I built the whole sequence by hand through Graph PowerShell in the lab, the real insight was not a technical one. The individual steps are unremarkable. The effort lies in putting them in the right order, writing each one so it can run a second time without doing damage, and knowing in the first place that somebody has left the company.