User Provisioning Automation for Onboarding, Changes and Offboarding

What user provisioning automation means for an Active Directory team

User provisioning automation is the practice of creating, changing and removing user accounts and their access from a defined input, by a script or workflow, instead of by an admin clicking through consoles. The three phases are called joiner, mover, leaver, because someone starts, changes role, or leaves. Together they are the user lifecycle.

Count what one new starter costs today. A ticket from HR, often incomplete. An account placed by memory in the right organizational unit (OU), the Active Directory container that decides which policies and delegated rights apply to it. Groups copied from a colleague who has collected memberships for six years. A mailbox, a license, a home folder, a welcome mail. Twelve to twenty clicks across four consoles, done differently by every admin. Now multiply by every department change and every leaver, where nobody even opens a ticket.

The goal is one process with three entry points, where every run starts from validated data, applies the same rules, runs under an identity with exactly the rights the task needs, and leaves a record of who asked for what. This article covers the three phases, the ways to build the automation, and the question most guides skip, namely who starts the process when HR and team leads hold no admin rights. The short answer is a self-service layer such as the au2mator Self-Service Portal in front of the scripts you already have, and the long answer follows below.

Joiner: onboarding from one request instead of twelve tickets

Automated onboarding starts with a data contract. Decide which values a request must carry (name, department, title, manager, start date, location) and which are derived from rules, such as the OU from the location, the groups from department and title, the license from the role, and display name and user principal name (UPN) from a naming convention. The fewer free-text fields, the fewer tickets come back as “wrong group”.

The script is not exotic. New-ADUser on Microsoft Learn creates the account with every attribute in one call, Add-ADGroupMember applies the memberships, Exchange and Microsoft Graph cmdlets handle mailbox and license, and a few lines create the home folder. What makes it employee onboarding automation rather than a helper script is the wrapper, which checks for an existing account, logs every step, mails the manager and returns a readable result.

One detail pays off later. Store the request parameters with the account, so the leaver process can undo what the joiner process did. In au2mator every request keeps its parameters anyway, which makes this step free.

Mover: the phase most teams skip

A joiner gets a ticket because the person cannot work without an account. A leaver gets one because HR documents the exit. A mover gets a mail from a team lead, if at all, along the lines of “Anna is now in Sales”. Her account keeps the Finance groups and gains the Sales ones. Three moves later she has access to half the company.

The mover process is the same script with a different contract, the user and the new values. It computes the target groups from the new department and title, compares them with the current set, removes what no longer applies, adds what is missing. Manager, title and license follow, and a mail goes to both managers.

If you automate only one phase after onboarding, make it this one. It is where permission creep is born.

Leaver: offboarding that actually finishes

Manual offboarding has a predictable shape. The account is disabled on the last day, and everything else happens “later”. Orphaned mailboxes keep their licenses, and the contractor who left in March still has a guest account in October.

An automated leaver process is a sequence with dates. On the last day it disables the account, resets the password, revokes sessions in Entra ID, removes all group memberships, moves the account to a leavers OU and forwards mail to the manager. After the handover period, typically 30 days, it converts the mailbox to shared, removes the license, hands OneDrive to the manager, and backs up and deletes the home folder. After retention it deletes the account. Each step is a scheduled job reading the stored leave date, so the sequence completes even if nobody remembers.

The same sequence, triggered with a future date, covers planned exits and contractor end dates. What it cannot replace is the trigger. Someone has to tell the process that a person is leaving, and that someone is usually in HR, not in IT. This is exactly the point where a “Leaver” request in au2mator replaces the ticket.

Four ways to build user provisioning automation

Most user provisioning software comparisons list ten products and skip the options you already own. There are four approaches, and the right one depends on scale, licensing and where your source of truth lives.

Two facts from Microsoft’s documentation shape the decision. HR-driven provisioning as described on Microsoft Learn can create accounts in on-premises Active Directory, but it needs a supported HR system or an API-driven feed as the authoritative source. Lifecycle Workflows require Microsoft Entra ID Governance or Entra Suite licensing and operate on Entra ID accounts, so the on-premises account must already exist through sync or another provisioning path. If your HR system has no connector, or your licensing stops at P1, your scripts remain the engine.

A script that creates a user is the same script whether a suite, a schedule or a person triggers it. The only question is who triggers it, with what rights.

The missing layer: how au2mator puts HR in front of your provisioning scripts

Here is the gap in most guides. The onboarding runbook needs seven values that only HR and the hiring manager know. Neither can start a runbook. So they open a ticket, an admin copies the values into the parameter block, and the automation saved the clicking but not the waiting. Movers and leavers suffer more, because nobody opens the ticket at all.

The au2mator Self-Service Portal closes that gap, and the design decision that matters is that it brings no engine of its own. Services are your PowerShell scripts, Azure Automation runbooks or Orchestrator runbooks. You keep the joiner, mover and leaver logic where it already runs and add a form on top. HR opens the portal and sees one service, “New employee”, with validated fields and no free text where it matters. Where a task warrants it, the manager approves in one click. Then a service account with exactly the rights the task needs runs the script, and the request lands in a log with requester, parameters, approver and result. HR never holds a right in the directory, and no admin copies values from a ticket again.

What an onboarding service looks like in au2mator

The service is your existing onboarding script, registered once in au2mator with its parameters. The form turns each parameter into a field, with dropdowns from Active Directory for department, manager and location. Permissions decide who sees what, so HR sees “New employee”, team leads see “Change department”, and nobody sees a console. Approval is optional per service, by the manager or a group owner. For execution, au2mator starts the script on PowerShell, Azure Automation or System Center Orchestrator, under a service account. Not one line of the script changes, and the result can be reported back to your ticketing tool. The audit trail stores every request with requester, parameters, approver and outcome. The same pattern serves the mover request from a team lead and the leaver request from HR. Our article on Active Directory delegation applies the same principle to help desk tasks, delegating the task rather than the permission.

Five steps to your first automated provisioning workflow

Write the process down. Sit next to the admin who does onboarding and record every click, console and value, and where each came from. This is your data contract and test case.

Turn it into a script. Parameters in, result out. Make it idempotent, log every step, and run it as a service account that can create users in the target OUs, nothing else.

Fix the data contract. Decide which values the requester supplies, which rules derive, and which come from AD itself. Every field moved from “typed” to “derived” removes a class of errors.

Put a form in front of it. Give HR and team leads an au2mator service with permissions per team and an approval where warranted. This is where the ticket queue shrinks, because the people with the information start the process themselves.

Measure and extend. Time per onboarding, tickets per starter, corrections per month. When the joiner numbers hold, add mover and leaver services on the same contract, and user lifecycle management becomes one process instead of three habits.

FAQ: user provisioning automation

Conclusion: one process, three phases, no admin rights at the front

User provisioning automation is not a product category you have to buy into. It is one process with three entry points, built from a data contract, a script that applies it, a service account that runs it and a log that remembers it. Onboarding is where you start because it has a ticket. Movers and leavers are where you win because they do not. And the layer that lets HR and team leads trigger a tested runbook themselves, without a single right in the directory, is what au2mator adds to the scripts you already own.

If you want to map your onboarding steps to that pattern and see which of your existing scripts could become a service next week, book a 30-minute call with Michael Seidl, Microsoft MVP and founder of au2mator, and bring the list of clicks from your last new starter.