Google Workspace does support SCIM. The practical question is whether it's worth building your provisioning and deprovisioning workflow on top of it. The practitioners who have actually tried to use Google Workspace as a provisioning IdP have a consistent answer: it's there, and it's more difficult to configure and manage than a real IdP. If you're starting with Google Workspace and trying to figure out how to automate user provisioning across your SaaS stack, the honest picture is that you'll hit limits quickly — and the commonly recommended path is pushing from Google into a proper IdP and letting the IdP handle downstream provisioning.

What Google Workspace SCIM Actually Supports (And What It Doesn't)

Google Workspace's SCIM support is primarily designed for inbound provisioning — receiving user data from an IdP like Okta, Entra ID, or Ping and using it to create or update Google Workspace accounts. Outbound provisioning from Google Workspace via SCIM — using Google as the source of truth to push user lifecycle events to downstream SaaS applications — is where the limitations concentrate.

The supported app catalog is small. The integration network for SCIM provisioning from Google Workspace consists mostly of Google's own products. The catalog of third-party applications that support Google-initiated SCIM provisioning is significantly smaller than what you'd find in Okta's or Entra ID's app galleries. Several practitioners in the thread described the catalog as frustratingly limited.

No custom SCIM configuration. Google Workspace's SCIM provisioning doesn't support custom configuration — you can't adjust attribute mappings, add custom fields, or modify the provisioning behavior for specific applications. What you see is what you get. For organizations with non-standard user schemas or applications that require custom SCIM payloads, this is a hard limit.

Difficult to use as an outbound IdP. One ISV engineer described trying to set up a provisioning integration with Google from the application vendor side: the process involved web forms with no follow-up mechanism, no clear team to contact, and no straightforward path. That experience reflects Google's general stance — they're better positioned as a SCIM target than a SCIM source.

App vendor support issues. Even for applications that theoretically support Google Workspace SCIM, vendor documentation is often sparse and the configuration options from the Google side are limited. The SAML side of the equation has similar friction — getting SAML SSO configured with Google as the IdP involves a different process than configuring it with Okta or Entra ID, and the tooling Google provides for vendors to build integrations is less developed.

Who Actually Uses Google Workspace SCIM

The use case where Google Workspace SCIM provisioning is most common and most justified: schools, universities, and value-oriented organizations that use Google Workspace as their primary directory and want basic lifecycle automation for the applications that support it. For these environments, Google Workspace is often the most practical identity system available, and SCIM provisioning — limited as it is — automates the provisioning for the small set of compatible applications.

For commercial organizations evaluating Google Workspace as their provisioning source, the picture is more complicated. Multiple thread respondents noted that Google's SCIM capability exists primarily as a feature checkbox rather than a mature enterprise provisioning platform. The organizations using it successfully tend to have simple environments — a small number of compatible applications, standard user schemas, and limited need for custom provisioning logic.

The Recommended Architecture: Google as Source, Real IdP for Provisioning

The most-endorsed recommendation in the thread was direct: push updates from Google Workspace to a proper IdP (Okta, Entra ID, Ping), and let the IdP handle downstream SCIM provisioning to applications. This bilateral SCIM approach uses Google Workspace for what it does well — directory management, Gmail, Google Drive, Google Meet — and delegates provisioning orchestration to an IdP built for it.

In practice: Google Workspace is the system of record for user identity. When a new user is created or an existing user is modified in Google Workspace, that change syncs to the IdP. The IdP evaluates the change, applies provisioning rules and group-based attribute mappings, and pushes the appropriate SCIM payloads to downstream applications. The downstream application set is governed by the IdP's integration catalog — Okta's or Entra ID's app galleries, which are substantially larger than Google's — rather than Google's limited SCIM catalog.

This architecture also resolves the custom configuration limitation. Attribute mapping, conditional provisioning logic, and application-specific SCIM customization are handled in the IdP's provisioning configuration, which offers the granularity that Google Workspace's outbound SCIM doesn't support.

The trade-off is adding an IdP layer and its associated licensing cost. For organizations already paying for Okta or Entra ID, the architecture is additive rather than a new cost. For organizations that wanted to use Google Workspace as a way to avoid IdP licensing, the recommendation to add an IdP reintroduces that cost.

How an IGA Platform Extends Google Workspace Without Requiring a Dedicated IdP

For organizations that want to use Google Workspace as their source of truth for user identity without adding a full IdP layer, an IGA platform provides a middle path.

Zluri connects to Google Workspace and continuously syncs user status — detecting when accounts are created, suspended, or modified. When a new user is created in Google Workspace, Zluri treats that event as the provisioning trigger and runs an onboarding playbook that provisions the user across downstream applications using direct API integrations rather than relying on Google's SCIM outbound capability.

The key advantage over Google SCIM: Zluri maintains over 300 direct API integrations with SaaS applications, covering applications that don't appear in Google's SCIM catalog and applications that don't support SCIM at all. For applications with no API surface — legacy tools, browser-based applications with login-only interfaces — Zluri's browser automation handles provisioning and deprovisioning without requiring an API.

For organizations managing Google Workspace as their primary directory and running offboarding manually, Zluri's offboarding playbooks handle the full Google Workspace deprovisioning sequence: signing the user out of all sessions, transferring Drive data to the manager, creating a group with the old email address for forwarding continuity, reclaiming the license after the configured grace period, and archiving or deleting the account. Each step executes automatically from the HR termination event, without manual tracking or follow-up.

The IGA approach doesn't replace the IdP-based architecture for organizations that already have Okta or Entra ID deployed. It's an alternative for organizations that want to retain Google Workspace as their directory without the overhead of an additional IdP layer, and where the provisioning complexity doesn't require the full feature set of an enterprise IdP.

Frequently Asked Questions

Does Google Workspace support SCIM provisioning?

Yes, but primarily as a SCIM target (receiving provisioning from an IdP like Okta or Entra ID) rather than as a SCIM source. Outbound SCIM provisioning from Google Workspace to downstream SaaS applications is supported but has a limited application catalog, no custom configuration options, and is generally considered less capable than provisioning from a dedicated IdP.

Why is Google Workspace a poor fit as a provisioning IdP?

Google's SCIM provisioning catalog for outbound integrations is much smaller than Okta's or Entra ID's. There's no support for custom attribute mapping or custom SCIM configuration. The vendor integration process for getting applications to work with Google-initiated provisioning is more difficult than with established enterprise IdPs. Google's SCIM support exists primarily for schools and value-oriented organizations rather than complex commercial environments.

What is the recommended alternative to Google Workspace SCIM for user provisioning?

The most common recommendation is pushing user changes from Google Workspace to a dedicated IdP (Okta, Entra ID, Ping) and letting the IdP handle downstream SCIM provisioning. This approach uses Google Workspace as the directory while delegating provisioning orchestration to an IdP with a broader integration catalog and more flexible configuration. IGA platforms like Zluri provide an alternative for organizations that want to skip the IdP layer and provision directly from Google Workspace events.

How do you automate user provisioning from Google Workspace without SCIM?

Direct API integrations with downstream SaaS applications handle the provisioning actions that SCIM would otherwise trigger. IGA platforms maintain these integrations centrally, so the provisioning logic responds to Google Workspace events (user creation, suspension) without requiring SCIM support in the downstream application. For applications without APIs, browser automation handles provisioning and deprovisioning through the application's UI.

Can Google Workspace handle role-based provisioning?

Yes, to a limited degree using Google Groups. Group membership can drive role-based access in some integrated applications. For organizations that need to map group membership to specific permission sets, license tiers, or application roles in downstream SaaS applications, the native Google Workspace capability is insufficient and an IdP or IGA layer is required.

See How Zluri Extends Google Workspace Provisioning Beyond SCIM

Most Google Workspace environments find that SCIM provisioning covers a small fraction of their application stack. See how Zluri's direct API integrations and offboarding playbooks automate the full user lifecycle from Google Workspace — including applications that don't support SCIM and offboarding steps that Google's native tools don't automate.