Microsoft 365 User Provisioning: 4 Approaches Compared Honestly

There are four serious approaches to provisioning Microsoft 365 users at scale. Every IT team eventually picks one, usually after trying at least two others. The decision rarely has a single right answer — it depends on team size, ops maturity, compliance requirements, and how much non-IT staff are involved in the workflow.

Here's how each one actually plays out in production. No vendor bias — every option has a real failure mode, and one of those failure modes is probably already biting you.

1. The M365 admin center (the default)

What it is: the web UI Microsoft ships with every M365 tenant. Click "Users → Active users → Add user," fill out the form, click create.

Strengths:

• Zero setup cost. It's there from day one.
• The UI is reasonably discoverable for IT pros.
• Every M365 admin already knows how to use it.

Failure modes:

• Manual. Every new hire is a fresh click-through of the same form. No templates beyond a basic "settings inheritance" pattern.
• Single-person bottleneck. Only Global Admins and User Administrators can use it (with the caveats we covered on User Admin — too broad for non-IT staff).
• No native scoping. A User Administrator using the admin center can create any user, with any license, in any group. There's no "HR can only create Sales department users with the Business Premium license" constraint.
• License assignment is a separate page. Group memberships are a separate page. Department/title fill is a separate page. A "complete" new-hire onboarding requires navigating through 4-5 admin center screens.

When it's the right answer:

• Tenants with fewer than 10 user-creation events per year (the per-user time cost doesn't compound)
• Single-IT-admin shops with no compliance or delegation needs

When it isn't:

• More than ~3 new hires per month — the manual time adds up
• Any scenario where you want non-IT staff to do the work
• Compliance environments where templates and audit are required

2. PowerShell scripts (the IT-power-user answer)

What it is: scripts that wrap the Microsoft Graph SDK or the older AzureAD/MSOnline modules. Typically maintained by one IT engineer, run from their workstation or scheduled on a server.

Strengths:

• Fully programmable. Anything Graph can do, the script can do.
• Templates are trivial (it's just a script with parameters).
• Repeatable, auditable in source control if you maintain it that way.
• No additional license cost.

Failure modes:

• One person can run it. The engineer who wrote it. When that person is on vacation, or leaves the company, the script either becomes a pain to use (everyone has to learn PowerShell + figure out the auth setup) or just stops being used.
• Auth is fragile. App registration permissions drift, certificate-based auth needs renewal, credential rotation breaks the script silently.
• Error handling is whatever the author bothered with. We've all seen the version that creates the user successfully, then fails on license assignment, leaves you with a half-provisioned account, and exits 0 because the author didn't check the second response.
• Audit is "whatever I logged to stdout."
• HR can't use it. Office managers can't use it. Anyone whose job isn't engineering can't use it.

When it's the right answer:

• One-person IT shops with strong PowerShell skills
• Specific automation needs that don't fit a SaaS model (bulk imports from a custom HRIS, conditional logic that depends on org-specific data)
• Plumbing layer underneath some other system that needs custom provisioning

When it isn't:

• You want a workflow non-IT staff can use
• You don't want the entire system to depend on one engineer's continued employment
• Compliance requires structured audit logs (not stdout)

3. IDaaS integration (the enterprise answer)

What it is: a dedicated identity provider — Okta, JumpCloud, OneLogin, Microsoft Entra ID with HR-driven provisioning, etc. — that connects to your HRIS (Workday, BambooHR, etc.) and provisions M365 users automatically when a new hire is created in HR.

Strengths:

• Fully automated. New hire created in HRIS → user appears in M365 on their start date.
• Bidirectional sync. Terminations in HRIS automatically disable M365 access.
• Audit is built-in.
• Scales to thousands of users.

Failure modes:

• Cost. Okta Workforce Identity starts around $4-12/user/month depending on tier. For a 50-person org that's $200-600/month just for the identity layer, on top of your M365 licensing.
• Setup time. Connecting Okta to your HRIS and configuring the M365 provisioning is typically a 2-6 week project, with significant ongoing maintenance for connector updates.
• HRIS dependency. If your HRIS data is incomplete or wrong (typos in department names, mistakes in job titles), those errors propagate automatically to M365.
• Overkill for SMBs without an HRIS or with a small enough team that the manual touchpoints don't matter.
• Doesn't solve the "delegate password resets to HR" or "let team leads add people to their Teams channels" problems — those are still IT-owned.

When it's the right answer:

• 200+ employees with a real HRIS
• Compliance environments where the audit-by-default of an IDaaS is required (SOC 2, HIPAA, financial services)
• Multi-app provisioning where M365 is just one of many systems the IDaaS feeds

When it isn't:

• Under 100 employees and no HRIS
• Cost-sensitive teams
• You want the ongoing user-management operations delegated to non-IT staff, not just the initial provisioning

4. Delegation portal (the focused middle ground)

What it is: a SaaS web app that sits on top of the Microsoft Graph API, exposing user-management operations (create, reset password, assign license, manage groups) through a focused interface designed for non-IT staff. Authenticates each user with their own OAuth token; constrains operations by portal role (Admin / Member / Viewer).

Strengths:

• Non-IT staff can use it. HR coordinator picks a template, fills in name + email, clicks create. Office manager resets a password in 30 seconds. Team lead adds someone to a Teams channel without filing a ticket.
• Templates lock down which licenses and groups can be assigned. HR can't assign an E5 license they don't have, or accidentally add someone to a sensitive security group.
• Audit log is built-in and reviewable by non-technical compliance staff.
• Per-tenant isolation for MSPs managing multiple clients (covered in detail in Why MSPs Should Stop Using Shared Admin Accounts).
• No standing access — the portal calls Graph with the signed-in user's token. When they sign out, there are no valid credentials to attack.

Failure modes:

• Doesn't replace your IT-pro workflows. PowerShell is still the right tool for one-off bulk imports, weird edge cases, or pre-existing automation.
• Doesn't replace IDaaS for genuine enterprise-scale identity ops. If you have Workday and 2000 employees, you want IDaaS, not a delegation portal.
• Requires admin consent at setup. One Global Admin click is needed to grant the app the Graph permissions it acts on behalf of users with.

When it's the right answer:

• 25-500 employees
• HR / office managers / team leads are involved in routine user ops
• You want to get people off Global Admin without recreating the bottleneck that put them there
• Compliance requires structured audit logs that non-technical staff can review

When it isn't:

• Fewer than 10 user events per year (overkill)
• Pure enterprise scale with mature HRIS integration (use IDaaS)
• Highly custom automation requirements that don't fit a generic interface (use PowerShell)

The honest decision matrix

Team size	HRIS?	Best fit
1-10 employees, 1 IT person	—	Admin center
10-50 employees, 1 IT person	—	Admin center + PowerShell for bulk
25-150 employees, 1-2 IT, HR doing onboarding	Maybe	Delegation portal
50-500 employees, IT team, HR + office staff involved	Maybe	Delegation portal
200-1000 employees, dedicated IT team	Yes	IDaaS, possibly + delegation for non-IDaaS ops
1000+ employees	Yes	IDaaS

The middle band — 25-500 employees, HR involved in onboarding, no HRIS or a basic one — is where most SMBs land, and where the delegation portal pattern is the right answer specifically. It's not what Microsoft's documentation defaults to recommending (they default to admin center or User Administrator), but it's what actually solves the problem most SMBs are dealing with.

UserDesk for M365 is built for this middle band. If you're already on PowerShell scripts and they work, great — keep them. If you're already on Okta with a Workday integration, that's the right enterprise answer. But if you're in the M365 admin center clicking through the same onboarding workflow 5 times a month and giving HR Global Admin to make it stop, you're the target customer.

See the delegation pattern: interactive demo at /demo. Sample tenant, no signup. 2 minutes to evaluate whether this is the right shape for your team.