You're a PM building a SaaS product that needs to support user provisioning from your customers' HR systems, CRMs, and identity providers — and you're trying to decide whether to build the integration layer yourself or rely on a broker like WorkOS. The answer depends heavily on which provisioning use case you're actually solving, because "user provisioning from an IdP" and "user provisioning from an HR or CRM system" are fundamentally different problems with different tooling options.

Two Provisioning Problems That Require Different Approaches

The commenter in the thread who called this "a complicated area" before separating it into two distinct use cases was giving the most useful framing in the discussion.

Provisioning from an Identity Provider — Okta, Azure AD/Entra ID, JumpCloud — is a solved problem with an open standard. Any decent IdP supports SCIM 2.0, which means if your SaaS application exposes SCIM endpoints, your customers' IT administrators can configure provisioning from their IdP to your application in their IdP's admin console. The integration work is on your application's side (implementing the SCIM API), not on building a connector to each IdP individually. SCIM handles create, update, deactivate, and delete operations across the full user lifecycle without custom code per customer.

Provisioning from a non-IdP system — Workday, BambooHR, Salesforce, custom CRMs — is not a solved problem. These systems aren't designed around user identity management. The records that represent people in a CRM aren't structured as "users" in the identity sense, and the systems don't expose push-based provisioning APIs the way IdPs do. Getting user records out of Workday and into your SaaS application requires either building a pull-based integration against Workday's API, using an iPaaS (integration platform as a service) layer that handles the field mapping, or relying on a provisioning platform that maintains native connectors for HR systems.

The OP's use case is the second, harder problem: customers want Workday to create users in the OP's SaaS application when certain criteria are met. That's not what SCIM alone solves — it's what an HR-to-application integration layer solves.

Why Building In-House Provisioning Integration Is Harder Than It Looks

Several practitioners in the thread explicitly recommended against building custom user provisioning infrastructure, and the reasoning is worth unpacking specifically.

SCIM adoption is lower than you'd expect. For IdP-to-application provisioning, SCIM is well-supported. For HR and CRM systems, SCIM support is inconsistent. Workday exposes APIs, but they're not SCIM — they're Workday-specific. BambooHR has an API, but its data model is HR-centric rather than identity-centric. Every HR system your customers use will have a different API structure, different authentication patterns, and different field mappings. Building a connector for each one is a substantial and ongoing engineering investment.

APIs change. The commenter who warned about brittle custom integrations was describing a real operational burden: as HR vendors update their APIs, add authentication requirements, or deprecate endpoints, someone on your engineering team has to find and fix the broken connector. For one or two HR systems, this is manageable. For a platform that needs to support the range of HR and CRM systems your customers actually use, it becomes a significant ongoing maintenance cost.

The data model problem. A Workday record that represents an employee contains payroll data, benefits information, manager hierarchy, cost center, and dozens of other fields that have nothing to do with provisioning a user in your SaaS application. Mapping the relevant fields — first name, last name, email, department, role, employment status — to the user schema your application needs requires transformation logic for every source system. That logic is different for every HR vendor, and it breaks when the HR system's data model changes.

Entitlements beyond account creation. Basic provisioning creates and disables accounts. Production provisioning needs to handle license assignment (which tier does this user get based on their role?), group membership (which features can they access?), and role-based permissions within your application. Building the logic to evaluate source attributes and map them to application-level entitlements is the layer where in-house builds most commonly fall short of what enterprise customers actually need.

One IAM-focused PM in the thread summarized the position clearly: the amount of effort to build user provisioning infrastructure, scale it, and keep it secure is not worth it. The recommendation was Okta for IdP-based provisioning and Auth0 (now part of Okta) for customer identity management. The team that built their own Keycloak-based solution said if they could start over, they'd use Auth0 — which is the kind of retrospective that's worth taking seriously.

What WorkOS and Similar Broker Platforms Actually Cover

WorkOS and similar developer-focused platforms (Scalekit, Clerk) provide pre-built SCIM and SSO integrations that let you add enterprise IdP provisioning to your SaaS application without building each IdP connector yourself. They abstract the IdP-specific implementation details so your application speaks to one API (WorkOS's) rather than separately to Okta, Azure AD, and Google Workspace.

The honest scope limitation, which one commenter identified by checking the WorkOS website: these platforms are primarily designed for IdP-to-application provisioning, not for provisioning from HR systems, CRMs, or other non-identity-native sources. If your customers want to provision users from their Workday instance rather than from their Okta tenant, a SCIM broker platform doesn't solve that problem.

The iPaaS path — connecting your application's data model to Zapier, Azure Logic Apps, or a similar integration platform — is more applicable to the non-IdP provisioning use case. Once your application's entities are represented in the iPaaS, customers can map fields from any connected system (including HR tools and CRMs) to create users in your application. The trade-off is that each customer needs to configure the mapping themselves, which requires technical sophistication that enterprise IT teams have but may not be appropriate for every customer segment.

How Third-Party IGA Platforms Handle the Full Provisioning Lifecycle

The use case the OP described — a user created in Workday that matches certain criteria triggers user creation in the SaaS application — is the core function of an IGA platform's inbound provisioning capability.

Platforms like Zluri maintain native connectors for HR systems including Workday, BambooHR, HiBob, Personio, and others. When HR adds a new employee in Workday, Zluri detects the event and triggers onboarding workflows based on the employee's attributes. The workflow can create the user in any connected SaaS application, assign the correct license tier and role based on department or title, and handle the full lifecycle — updates when attributes change, deprovisioning when employment ends — without requiring the SaaS application's team to build or maintain the Workday connector.

For SaaS vendors building enterprise provisioning support into their own product, Zluri's Integration SDK provides the alternative to full native connector development: a lightweight API that lets you push user, license, and role data from your application into Zluri's governance layer, enabling your customers to manage your application's users alongside the rest of their SaaS stack. This covers the proprietary and custom-built application scenario without requiring your team to build the full IGA infrastructure from scratch.

The lifecycle management that matters for enterprise SaaS customers extends beyond create and disable. When an employee changes roles, the platform runs a mover workflow that revokes access tied to the old role and provisions access for the new one, preventing privilege creep without custom automation. When employment ends, the offboarding workflow handles license reclamation, session termination, and data transfer — the steps that most basic provisioning integrations leave as manual processes.

For compliance-sensitive customers, the audit trail that comes with a governed provisioning platform — who was granted access, who approved it, which system triggered it, when it was revoked — is a buying criterion in enterprise sales cycles. Building that audit infrastructure in-house, with the immutability and queryability that compliance frameworks like SOC 2 and GDPR require, is one of the highest-effort components of any custom provisioning build.

Frequently Asked Questions

What is the difference between SCIM provisioning and HR-to-SaaS provisioning?

SCIM provisioning moves user data between an Identity Provider (Okta, Entra ID) and a downstream application using a standardized protocol. Both sides speak SCIM. HR-to-SaaS provisioning moves user data from an HR system (Workday, BambooHR) to an application, which requires connecting to the HR system's native API, transforming HR-centric data into the application's user schema, and handling the logic of when to create, update, or deactivate users based on employment status.

Should a SaaS company build user provisioning in-house or use a third-party tool?

For IdP-based provisioning (Okta, Entra ID, Google Workspace), implementing SCIM on the application side and using a broker platform like WorkOS is faster and lower-maintenance than building per-IdP connectors. For HR and CRM-based provisioning, third-party IGA platforms or iPaaS tools are strongly recommended over custom builds — the ongoing maintenance cost of custom HR connectors typically exceeds the licensing cost of a purpose-built platform.

What are the limitations of WorkOS for user provisioning?

WorkOS is primarily designed for IdP-to-application provisioning via SCIM and SSO. It handles enterprise IdP integration well. It doesn't maintain connectors for non-IdP sources like Workday, BambooHR, or CRM systems, which is the more complex provisioning use case for SaaS products that want to provision users from customers' HR infrastructure.

How do you provision users from Workday into a SaaS application?

Options include: building a custom connector against Workday's API (high maintenance, brittle); using an iPaaS like Azure Logic Apps or Zapier with Workday and your application connected (requires customer-side configuration); or using an IGA platform with a native Workday connector that handles the full lifecycle — creation, updates, and deprovisioning — automatically based on employment events in Workday.

What is the build vs. buy decision for user provisioning infrastructure?

Build makes sense when your provisioning requirements are narrow (one or two well-documented sources, standard SCIM), you have dedicated engineering capacity for ongoing maintenance, and your customers' needs won't expand to new HR systems or CRM sources over time. Buy makes sense in most other scenarios — the maintenance burden of custom HR connectors, the audit trail requirements of enterprise compliance, and the breadth of source systems enterprise customers use collectively make third-party platforms more economical at scale.

See How Zluri Handles Multi-Source Provisioning for SaaS Environments

SaaS products that add enterprise provisioning support often discover that Workday and BambooHR are only the first two of many HR systems their customers use. See how Zluri's native HR connectors and Integration SDK handle multi-source provisioning — and what the full JML lifecycle looks like for your specific application and customer base.