New Hires Were Sitting Idle for Hours on Day One. Here's the n8n Workflow That Fixed It.

The first tell was always the Slack message. Something like: "Hey, [name] started today — she still can't log in anywhere." Sent around 10am. Which meant the person had been in the building for at least two hours, laptop open, unable to do anything.

This happened more than once at a large international NGO I worked with that had staff spread across dozens of offices and field sites. New-hire provisioning was entirely manual. HR would email IT — sometimes the day before the start date, sometimes the morning of, occasionally a week late. IT would then spend 45 minutes to an hour creating the Entra ID (then Azure AD) account, assigning licenses, adding the person to the right distribution lists and Teams channels, and sending credentials to the manager. On a busy Monday with two or three new hires across different offices, something always slipped: a Teams channel not added, a license seat not confirmed, a welcome email that went to the wrong address.

The failure wasn't a process design problem. Everyone knew what needed to happen. The failure was dependency: the entire chain relied on HR remembering to send an email at the right moment, IT being available to action it, and neither getting lost in the queue. Any one of those broke the chain.

The Trigger Problem

Before you can automate new-hire provisioning, you have to solve one upstream question: what event starts the workflow?

In an ideal environment, your HRIS (Workday, BambooHR, whatever) fires a webhook the moment an employee record moves from "offer accepted" to "active." In practice, many mid-sized organizations — and nearly all NGOs and nonprofits — don't have that webhook configured, or IT doesn't control the HRIS integration.

My solution: a Google Form that HR fills out once a start date is confirmed. One form. About a dozen fields: legal name, preferred display name, start date, department, manager email, office location, whether they need a shared mailbox, and which two or three Teams channels they should join on day one. That form posts via webhook directly to n8n.

If your HRIS supports webhooks, use it. The form-to-webhook approach is a workaround, not a recommendation. But it is a reliable one — it gives HR a consistent, low-friction interface, and it gives n8n a clean, structured payload instead of the variable text of an email. The requirement is just one canonical trigger. A free-form email thread IT has to monitor is not a trigger; it's a liability.

What the Workflow Does

Once n8n receives the form submission, the workflow runs in roughly this sequence:

1. Create the Entra ID user. An HTTP Request node calls the Microsoft Graph API (POST /users) with the display name, UPN, department, manager reference, and a randomly generated temporary password. The account is created disabled — credentials don't go anywhere until everything else is confirmed in place.

2. Assign licenses. A second Graph call (POST /users/{id}/assignLicense) attaches the appropriate Microsoft 365 plan. License assignment takes a few minutes to propagate, so I add a Wait node here — roughly 3 minutes — before the next steps try to act on the account.

3. Add to security groups. Each department has a corresponding Entra ID security group that governs access to SharePoint sites, internal tools, and shared resources. The workflow maps department name to group ID via a Switch node and runs a POST /groups/{groupId}/members/$ref call for each applicable group. I keep the group-ID map as a simple JSON object in n8n's variables; it takes about 10 minutes to update when a new group is added.

4. Add to Teams channels and distribution lists. The n8n Microsoft Teams node handles channel membership more cleanly than raw Graph calls for this step — easier to read, easier to debug. Distribution list membership goes through the same Graph pattern as security groups.

5. Enable the account and notify the manager. Once every provisioning step completes, the account gets enabled. n8n sends the manager an email with the temporary credentials, a short "Day One checklist" note (change password, confirm MFA setup, check Teams channels), and a reminder that the temporary password expires in 24 hours. The manager gets the credentials, not the new hire's personal email — we haven't verified they control it yet.

The whole sequence from webhook receipt to sent email runs in about 5 to 6 minutes, most of which is the license-propagation wait. The provisioning steps themselves are fast.

What Actually Changed

Before the workflow: average time from "new hire start date confirmed" to "accounts ready" was roughly 90 minutes when everything went smoothly, and considerably longer when the notification came in during a busy morning or got missed until after lunch. There were onboarding events where the new hire had active credentials on day two because day one ran out of time.

After: the workflow fires the moment HR submits the form — which HR now does the week before the start date as part of their own process, because we asked them to and made the form the path of least resistance. Accounts are ready before Day One. The Day One Slack message stopped appearing.

The Day One Slack message stopped appearing. That's not a metric I tracked formally, but it's the one that mattered to me.

The less visible improvement was consistency. Manual provisioning had a long tail of partial errors — a security group skipped, a Teams channel missed. The n8n workflow either completes every step or fails loudly: if any node errors, a separate error handler sends an alert to the IT inbox with the specific step and payload that broke. There's no partial-onboarding grey zone where you're not sure whether the person has SharePoint access or not.

What I Still Touch Manually

Device provisioning is the obvious gap the workflow doesn't close. Creating accounts is network-only; getting a configured laptop into someone's hands still requires physical steps. I haven't automated device assignment — the edge cases (hardware availability, shipping to remote locations, swap requests) involve judgment that isn't worth encoding yet.

Role-specific permissions are the other area I handle by hand. Security groups manage the broad strokes, but some roles need access to specific systems not covered by group membership — particular CRM instances, billing tools, legacy on-prem apps with their own user management. I keep a short per-department checklist for these and run it after confirming the automated steps completed. The checklist itself lives in SharePoint and took about 30 minutes to build once across all departments.

The goal isn't to automate everything. It's to automate the repetitive, error-prone core and leave the judgment calls for a human who has time to think about them because the repetitive part handled itself.

The Companion to Offboarding

If you've already built an offboarding workflow — I wrote about that here — the onboarding workflow shares almost the same infrastructure: the same Microsoft Graph API connection, the same security group logic in reverse, the same Entra ID node setup. The two workflows share a library of group-ID mappings and API credentials. Building one makes the other substantially faster to build.

The one thing both workflows have in common that's easy to underestimate: the quality of the trigger. For offboarding, the trigger is an HR departure signal or a ticket. For onboarding, it's the form submission or HRIS webhook. Both workflows are only as reliable as the event that starts them. Invest the time in making that signal clean and consistent, and the automation holds up. Let the trigger stay informal — an email people sometimes forget to send — and you'll spend your time debugging the process, not the workflow.

Where to Start If You're Not There Yet

If new-hire provisioning is currently someone's interrupted morning:

1. Get HR to use one form. Google Form, Typeform, a Jotform, whatever. The format doesn't matter — a clean, structured signal does. This step matters more than any of the automation that follows.
2. Automate account creation first. The Entra ID user creation via Microsoft Graph is the highest-value step and a self-contained API call — five or six nodes in n8n, including a test run. Start there before adding license assignment or Teams channels.
3. Add each feature as its own sprint. License assignment, security groups, Teams channels — each adds about 20 to 30 minutes of build time once the base workflow exists. Build incrementally. A workflow that reliably creates the account and assigns a license is already 60% of the value.
4. Build a failure notification before you go live. If any node errors, you need to know immediately — before the new hire arrives. A simple error handler that Slacks or emails the IT inbox on failure is non-negotiable. Without it, silent failures are invisible until a new hire is already sitting idle.

The full workflow took me about half a day to build and test the first time. Subsequent additions — new security groups, new department mappings, new Teams channels — each take under 30 minutes. The form takes about 10 minutes to set up and share with HR.

If you're setting this up and want a second opinion on the workflow structure or Graph API call pattern, get in touch. The architecture is generally consistent across environments — the variation is in how clean your group-ID mapping is and what your HRIS can actually signal.