The Problem with Manual Onboarding
The average MSP onboarding still runs 2–4 hours of technician time per user. That number hasn't budged in years, because the steps involved — creating accounts, assigning licenses, enforcing MFA, applying Conditional Access policies, enrolling in EDR, scoping backup coverage — live across half a dozen consoles with no native orchestration between them.
Manual processes fail in predictable ways. MFA registration isn't enforced. Conditional Access policy gets applied to the wrong group. The device never gets tagged into the EDR policy. The new hire shows up on day one and none of it is right, or worse — it looks right but has subtle misconfigurations that won't surface until something goes wrong.
Here's the gap that keeps me up at night: the window between "user created in Entra ID" and "user fully hardened across the stack" is where breaches happen. An account that exists but isn't protected by Conditional Access or device compliance policies is a half-open door. In most MSP shops, that window is measured in hours. For us, it's now under 90 seconds — and the pipeline documents every step.
What the Pipeline Does, In Order
The pipeline is a PowerShell orchestration layer with Claude handling structured intake parsing and output generation. Here's the execution sequence:
Step 1 — Intake. A new-hire intake form is submitted via our PSA (ConnectWise). It carries structured fields: full name, department, manager, start date, license tier (Business Basic, Business Premium, or E3), and any custom group memberships. Claude reads the intake ticket, validates the data, and generates the PowerShell parameter block — essentially pre-filling the variable declarations the script needs to run. This step takes about 8 seconds and eliminates transcription errors entirely.
Step 2 — M365 provisioning. The script creates the account via the Microsoft Graph API, assigns the correct license, and immediately triggers MFA registration enforcement. A Temporary Access Pass (TAP) is generated — a time-limited, one-time credential the new hire uses to complete their authenticator setup on day one. The TAP is delivered directly to the hiring manager, not the new user's personal email, so the handoff is controlled.
Step 3 — Entra ID configuration. The account is added to the correct security groups, which in turn apply the appropriate Conditional Access policies and Intune compliance baselines. Device enrollment prompt is staged so it fires on first login. This is where most manual processes fall apart — Conditional Access is often configured at the group level but groups aren't assigned consistently. The script doesn't skip it.
Step 4 — Defender for Endpoint. The onboarding package for Microsoft Defender for Endpoint is staged and associated with the device enrollment policy. When the device checks in, it's picked up automatically. No technician needs to manually push a package or chase down whether it landed.
Step 5 — SentinelOne. The site token for the client's SentinelOne instance is pushed to the device enrollment policy. SentinelOne's agent deploys automatically via Intune during the OOBE or on next policy sync. Like Defender, this is zero-touch once the pipeline has run.
Step 6 — Backup scope. The new user is added to the Veeam Microsoft 365 backup job for the client. This is the step that gets skipped most often in manual workflows, because it lives in a completely separate console with no alert when a new account appears. Forgetting it means the user's mailbox and OneDrive aren't in the backup scope until someone notices — which could be months later.
Step 7 — Output. Claude generates a formatted onboarding summary email to the hiring manager. It includes the TAP with instructions for use, a first-day IT checklist (how to enroll the authenticator, how to complete device enrollment, who to call if something doesn't work), and a PSA ticket closure note that documents every action taken, the script version that ran, and the reviewing technician's name.
The Human Review Gate — Non-Negotiable
Before any of those steps execute against a live client tenant, the script runs in dry-run mode and outputs a complete preview to the PSA ticket. The technician reads it. They confirm the license tier is correct, the groups are right, the manager email address is accurate. Then they approve the run.
Only after explicit technician approval does the pipeline execute.
We do not auto-execute tenant changes. Full stop. This isn't a limitation we're trying to engineer around — it's a deliberate policy. Client tenants are production environments. A script that runs without human sign-off, even a correct one, is one configuration drift event away from being a problem. The review gate costs about 60 seconds of technician attention. That's the right trade.
The approval is logged in the PSA ticket with a timestamp and the technician's name. When we close the ticket, the audit record shows who reviewed the dry-run, when they approved, and what version of the pipeline ran. That record matters for more than just compliance — it's what you hand to a client when they ask "how was this user provisioned?"
What We Deliberately Didn't Automate
The scope of the pipeline is as important as what it does. Three things are permanently outside it:
Device setup. Physical device prep — unboxing, OOBE configuration, app deployments specific to a user's role — has too many variables to template safely. Intune handles policy-based configuration, but the hands-on work of validating that a specific line-of-business application is working correctly before the user's first day requires a technician who can see the screen. We don't rush that with automation.
Application-specific permissions. SharePoint site access, CRM role assignments, ERP user creation, line-of-business app licensing — these are too client-specific to handle with a generic template. Getting them wrong in either direction (under-provisioned or over-provisioned) has real business and security consequences. These get handled as separate tickets driven by the hiring manager's input, not assumed from the intake form.
The first call with the user. You can't automate trust. Every new hire gets a 10-minute call with a Primetime technician before or on their first day. We walk through security expectations — what phishing looks like, how to report a suspicious email, what to do if they get an unexpected MFA prompt. No automated email or checklist replaces that conversation. The human element of security awareness training has to be human.
Why This Matters Beyond Labor Savings
The labor savings are real — we've reduced billable provisioning time from 2+ hours to under 15 minutes of technician attention (intake review, dry-run approval, first-call scheduling). But the more important outcome is documentation consistency.
Every manual step that a technician performs from memory is also a step that may or may not be documented. And inconsistent documentation is a liability — when the cyber insurance auditor asks you to demonstrate your onboarding process, "we follow a checklist" isn't the same as "here is a closed-loop audit record for every user provisioned in the last 24 months, showing what was configured, when, by whom, and under which script version."
The pipeline generates that record automatically. Every hire. Every time. When a client asks us to demonstrate security controls during a vendor assessment or insurance renewal, we can show them a complete, timestamped record of exactly how their environment was configured — not reconstruct it from memory or email threads.
That's the real deliverable: not speed, but confidence. Confidence that the onboarding process executed correctly, that nothing was skipped, and that the record exists to prove it.
Laz De La Vega
Laz De La Vega leads Primetime IT Solutions, a managed IT and cybersecurity practice serving South Florida businesses since 2005.
Learn more about Laz →