Your HR team has chosen ADP, you're expecting 100+ hires this year, and manual user creation is already a hassle before the growth hits. You've looked at ADManager Plus and Adaxes, and you've correctly identified the risk with homegrown PowerShell systems: when the developer who wrote them leaves, the institutional knowledge leaves with them. The question isn't whether to automate — it's which commercial option fits an ADP-to-AD-to-O365 workflow without creating a new maintenance dependency.

What the Thread Recommends (And the Economics Behind Each Option)

The r/sysadmin discussion on this question surfaced a useful range of perspectives, and the OP's own framing — "we have people with the skills to do this in PowerShell BUT we do not want a $100K/year sysadmin-developer to spend too much time on this when ADManager Plus will do it for $5K, simple economics" — is exactly the right way to frame the build-vs-buy decision at this scale.

PowerShell was the most-upvoted recommendation, as it almost always is in these threads. The honest version: it works, it's free, and a competent sysadmin can build a functional new hire script in a few days by cobbling together examples. One commenter described doing exactly this with zero prior PowerShell knowledge, arriving at a long and ugly script that nonetheless worked. Another described the architecture: HR submits a Microsoft Form, Power Automate adds their answers to an Excel spreadsheet formatted as a CSV, the CSV feeds the PowerShell script as user attribute variables. That's a real system. The OP's objection to it — developer dependency, maintenance risk — is also real. A homegrown system is only as maintainable as its documentation and the sysadmin who inherits it.

ADManager Plus was on the OP's evaluation list and came up in the thread with mixed reviews. One commenter noted slow helpdesk support response times. Another described positive experiences with ManageEngine products generally. It handles AD-centric provisioning well with template-based role logic — one commenter described a template that assigns appropriate groups, enables MFA, and adds MS licenses depending on role. The limitation is that it's fundamentally an AD management tool rather than a full lifecycle governance platform, which matters when the provisioning scope extends beyond AD to SaaS applications.

Adaxes was the other tool the OP was evaluating and received consistent endorsements in the thread. One commenter described it as more of a scheduling and delegation tool in their environment — password self-service and security group management — rather than a full provisioning automation platform. Another paired it with PowerShell as a combination. For AD-specific automation with business rule enforcement, it's a legitimate option. The question is whether the scope stays AD-only or needs to extend to O365 licensing and SaaS application provisioning.

ARM templates with Azure came up from one commenter who migrated a highly manual process into a linear flow using ARM templates — noting that any competent Azure admin could maintain it from the KB documentation, which directly addresses the OP's continuity concern. Requires JSON proficiency and PowerShell knowledge, which is a different skill profile than pure AD administration.

The OP's economics point is worth taking seriously: if ADManager Plus or Adaxes costs $5K and a developer-sysadmin costs $100K, the commercial tool wins on cost even if it handles 80% of the problem. The remaining 20% — the cases the tool handles awkwardly or requires workarounds for — is where the evaluation needs to be honest about what's being accepted.

Where AD-Centric Tools Run Out of Runway

ADManager Plus and Adaxes both handle the AD provisioning problem well. The scope that matters for a growing company hiring 100+ people per year extends beyond AD account creation in ways that are worth naming before committing to a tool.

O365 license assignment is partially handled by AD group membership (if group-based licensing is configured in Entra ID), but ensuring the right license tier is assigned based on role — not just any license — requires either careful group configuration or a provisioning platform that understands license types and can assign them conditionally.

SaaS application provisioning beyond O365 is where purely AD-centric tools stop. If new hires need Slack access, a CRM, a project management tool, or any application outside the AD/O365 ecosystem, those provisioning steps are either manual or require separate automation for each application.

Termination completeness is the risk that grows fastest with headcount. Disabling the AD account handles O365 and SSO-connected applications. It doesn't revoke access to applications where the user has separate credentials, where access was granted outside SSO, or where shadow IT tools were adopted informally. At 100 hires per year, the accumulation of orphaned accounts in non-AD applications becomes a meaningful security and compliance exposure.

Reporting for compliance — the OP specifically mentioned reporting as a requirement — needs to cover the full access picture, not just what's in AD. If an auditor asks who had access to which systems over the past year, AD logs cover the AD-connected systems. Everything else requires separate reporting or a governance platform that maintains a unified access record.

How a Dedicated IGA Platform Covers the Full ADP-to-AD-to-O365 Chain

The architecture that handles the full provisioning scope — ADP as the event source, AD provisioning, O365 license assignment, SaaS application provisioning, and reporting — is what IGA platforms are built for.

Zluri connects to ADP via API, reading the fields that drive provisioning decisions: hire date, termination date, assignment status, job title, and department. The moment HR adds a new hire in ADP with a future start date, Zluri detects the record and triggers an onboarding playbook. No manual import, no polling script that runs every 15 minutes — the event triggers immediately when the HR record is created.

For on-premises Active Directory, Zluri's lightweight LDAP agent connects to the internal network and syncs user accounts, group memberships, and OUs as part of the onboarding workflow. AD account creation, group assignment, and OU placement happen automatically based on the department and role attributes from ADP. Once the AD account syncs to Entra ID, O365 license assignment runs in the same workflow — birthright access provisioning assigns the specific license tier and O365 application access appropriate to the new hire's role, not a generic license assignment.

For SaaS applications beyond O365, the same playbook extends provisioning to any application in Zluri's integration library — Slack, CRMs, project management tools, and others — using the same conditional logic that determined the O365 license tier. A sales hire gets Salesforce provisioned in the same workflow as their AD account and O365 license.

At termination, when HR updates the termination date in ADP, Zluri catches the status change and runs an offboarding playbook: AD account disabled, O365 licenses revoked, active sessions terminated, and downstream application access deprovisioned. The discovery engine identifies every application the user had access to — including tools outside SSO coverage — so the offboarding scope covers the full access picture rather than just what AD-connected tools see.

The reporting requirement is addressed through Zluri's reports module: organization-wide user lists, active application access by user or department, software spend, and immutable audit logs capturing every provisioning and deprovisioning action. When compliance requires evidence of who had access to what and when, that record is available without reconstructing it from AD logs and email trails.

What to Evaluate Before Committing to Any Tool

Given that the OP was already in demos with ADManager Plus and Adaxes, a few specific questions worth working through with each vendor:

How does it handle the ADP-to-AD provisioning trigger? Is it webhook-based (real-time) or polling-based (scheduled)? For a company hiring 100 people per year, a daily sync may be acceptable. For companies with same-day hire events, real-time matters.

What happens to O365 licensing? Does the tool handle license tier assignment conditionally based on role, or does it assign a default license? The difference is meaningful at scale when license costs vary by tier.

What's the offboarding scope? Does deprovisioning cover only AD-connected applications, or does the tool have a discovery mechanism for SaaS access outside SSO? At 100+ hires per year, offboarding coverage is a security question, not just an operational one.

What's the reporting output? Is it AD-focused (who's in which group) or governance-focused (who has access to which applications, with approval history)? The compliance use case requires the latter.

What's the continuity story? The OP specifically flagged developer dependency as a risk. For each tool, the question is: if the person who configured this leaves, can a competent IT admin maintain and modify it from documentation, or does it require specialized knowledge to operate?

Frequently Asked Questions

How do you automate user provisioning from ADP to Active Directory and Office 365?

The standard approach is connecting ADP as the event source (via API or webhook), routing the hire and termination events through a provisioning platform, and executing AD account creation and O365 license assignment automatically based on the HR record attributes. Tools in this space include ADManager Plus, Adaxes, and IGA platforms like Zluri, each with different scope and complexity trade-offs.

What is the difference between ADManager Plus, Adaxes, and a full IGA platform?

ADManager Plus and Adaxes are AD-centric tools that handle Active Directory provisioning, group management, and lifecycle automation well. IGA platforms like Zluri extend that scope to SaaS application provisioning beyond AD, access reviews, SoD controls, and a unified audit trail across the full application stack. The right choice depends on whether your provisioning scope stays AD-centric or extends to the broader SaaS environment.

How do you avoid a single-developer dependency in a homegrown provisioning system?

Documented commercial tools with standard configuration interfaces are the standard solution — any IT admin familiar with the platform can maintain and modify configurations without needing to understand custom code. The key evaluation criteria: is the configuration expressed in a UI that any competent admin can navigate, or in custom scripts and JSON that require specialized knowledge?

What should the termination workflow cover for an AD and O365 environment?

Minimum: AD account disabled, O365 licenses reclaimed, active sessions terminated. Complete: all SaaS applications deprovisioned including those outside SSO coverage, shared mailbox conversion, data transfer to manager, audit trail of every action. The difference between minimum and complete becomes meaningful when an auditor asks about a specific terminated employee's access 12 months later.

Does ADP support automated provisioning integration with Active Directory?

ADP has API access that allows provisioning platforms to read employee records including hire date, termination date, job title, and department. The provisioning platform uses these as triggers for AD account creation and deprovisioning. Microsoft also offers a Workday-to-AD SCIM connector natively; ADP integration typically requires a third-party provisioning platform or custom API integration.

See How Zluri Connects ADP to Your AD and Office 365 Environment

Companies hiring 100+ people per year typically discover the limits of manual provisioning faster than expected — and the limits of AD-only tools shortly after. See how Zluri's ADP integration handles the full provisioning chain — from hire event to AD account to O365 licensing to SaaS application access — and what the termination workflow looks like for your specific environment.