You've established M365 or Google Workspace as your source of truth. Users are federated via SSO where applications support it. You're removing users from AD/Entra ID groups to revoke SSO-connected access. And then there's the other category: the applications that don't support SSO at the tier you're on, the ones that don't support SCIM even if they support SSO, and the ones that don't support either. The thread this question generated is one of the more honest in this space — the top commenter's conclusion is that if a portal has no way to integrate SSO for any amount of money, your options are a checklist or push it to HR as their problem. Neither is ideal. The question is what's available in between.

The Three Tiers of SaaS Integration (And Where Provisioning Breaks Down at Each)

Understanding why automation is incomplete for most SaaS stacks requires being honest about the three categories every application falls into.

Tier 1: SSO and SCIM supported. For these applications, the provisioning story is close to complete. An Entra ID or Okta user in the right group gets provisioned via SCIM when they're added, and deprovisioned when they're removed or their account is disabled. Role assignment can be handled through SCIM attribute mapping or app roles. This is how the enterprise IdP ecosystem was designed to work, and for the applications in this tier, it does.

Tier 2: SSO supported, SCIM not supported (or gated behind enterprise pricing). This is where the SSO tax creates the gap. The application supports SAML or OIDC for authentication, but hasn't implemented SCIM — or has implemented it only at the enterprise tier. You can federate the login, which means disabling the user in Entra ID blocks their ability to authenticate. What you can't do is automatically provision them when they join, manage their application-specific role assignments, or trigger graceful deprovisioning actions (data transfer, archiving, license reclamation). The top commenter in the thread identified the practical resolution: upgrade to the tier that includes SCIM, switch to a competitor that supports it, or accept that these applications require a checklist.

Tier 3: No SSO, no SCIM, no API. These applications are outside the reach of any IdP-native automation. The commenter who described this category accurately: you're SOL and need to manage them manually. The only realistic alternatives are a checklist with a human following it, or delegating responsibility for those tools to the business unit that owns them.

The honest version of the automation story for most organizations: Tier 1 is automated, Tier 2 is partially automated (SSO gives you a deprovisioning signal but not full lifecycle management), and Tier 3 is manual. The question is how to shrink the manual category without paying for every vendor's enterprise tier.

What MSPs and IT Teams Are Actually Doing for Non-SCIM Apps

The thread surfaced the practical approaches teams have landed on, and they reflect the tier structure above.

Push every app to SSO first. The most-upvoted recommendation: for any app in Tier 2, the priority is getting SSO configured before anything else. SSO doesn't give you full provisioning automation, but it gives you a deprovisioning signal — disable the IdP account, and the user can no longer authenticate. For applications where the risk is lingering post-termination access rather than slow onboarding, SSO is the highest-value first step.

Upgrade licensing for SCIM where the volume justifies it. The commenter's framing was direct: instead of paying for a third-party tool to handle provisioning for an app, save that money and buy the enterprise license that includes SSO and SCIM. For applications where you have enough users that provisioning overhead is significant, the math often works out.

Custom workflow automation. One commenter described handling provisioning through a custom workflow in Autotask. This is the MSP equivalent of the SuiteScript approach — custom-built orchestration that bridges the gap for specific applications. Works, requires ongoing maintenance, doesn't generalize well across different clients or applications.

Custom iPaaS integrations. For applications with non-standard APIs, building an integration in Azure Logic Apps, Make (formerly Integromat), or a similar iPaaS handles the specific app without requiring a full IGA platform. The limitation is that it's per-application — each non-SCIM app needs its own integration configured and maintained.

Managed checklists for Tier 3. For applications with absolutely no integration path, the checklist is the answer. The commenter who suggested pushing responsibility to HR or the business unit for tools IT can't govern is describing a real governance model — some tools are business-owned, not IT-owned, and the business unit should be responsible for managing access in tools they control.

How IGA Platforms Handle the Non-SCIM Gap at Scale

The category of tool the OP was looking for — something that goes beyond SCIM to handle the applications that don't support it — is what IGA platforms address with their integration libraries and fallback mechanisms.

Zluri maintains over 300 direct API integrations with SaaS applications, covering applications that don't appear in IdP SCIM galleries but do have APIs. For these applications, Zluri executes provisioning and deprovisioning directly via the application's native API rather than through a SCIM protocol. The provisioning actions are more specific than what generic SCIM supports: signing a user out of all sessions, transferring Drive data to a manager, reclaiming a specific license tier, assigning a specific application role — not just creating and deleting accounts.

For Google Workspace, Zluri handles the full offboarding sequence: session revocation, Drive data transfer, email forwarding via group creation, OU move, license reclamation, and account archival. For Adobe Creative Cloud, it manages group assignment and license allocation. For DocuSign and Salesforce, provisioning and deprovisioning run through their native APIs.

For the Tier 3 category — applications with no API surface at all — Zluri's automated manual task routing is the practical answer. When the offboarding playbook reaches an application it can't deprovision automatically, it generates a task assigned to the designated owner (the business unit admin, the application owner, whoever manages that tool), delivered via email, Slack, or ITSM ticket. The task owner marks it complete; the action is logged. The manual step exists inside the workflow rather than as an informal off-system process that may or may not happen.

For MSP environments where the same provisioning architecture needs to scale across multiple clients, each with different SaaS stacks, this matters specifically: the per-client configuration defines which applications are in scope, which are automated, and which fall through to managed manual tasks. The framework is consistent; the application coverage adapts per client.

The SSO Tax and What To Do About It

The OP's comment — "licensing hurdles and poor implementation of proper SSO/SCIM makes this a nightmare" — names the SSO tax directly. Vendors charging enterprise pricing to unlock SCIM and SAML is a well-documented pattern that exists primarily because identity integration capability is a feature vendors monetize rather than provide as a baseline.

The practical responses are limited. Upgrade to the enterprise tier (expensive but clean). Switch to a competitor that includes SSO and SCIM at lower pricing (sometimes viable, often not). Accept manual management for that application (manageable for low-frequency access changes, not for high-turnover environments). Use an IGA platform with a native API integration that doesn't depend on the vendor's SCIM implementation.

The last option is the closest to the "magic wand" the OP acknowledged doesn't exist — but it's not magic, it's a maintained API integration library that shifts the integration maintenance cost from your team to the platform vendor. The trade-off is licensing cost versus engineering time.

Frequently Asked Questions

How do you automate provisioning and deprovisioning for SaaS apps that don't support SCIM?

Options depend on what the application does support. If it has an API, direct API-based provisioning via an iPaaS or IGA platform handles lifecycle management without SCIM. If it supports SSO but not SCIM, federated authentication at least gives you a deprovisioning signal when the IdP account is disabled. If it supports neither, the practical options are a managed checklist or delegating governance to the business unit that owns the tool.

What is the SSO tax and how does it affect provisioning automation?

The SSO tax refers to vendors gating SCIM and SAML support behind enterprise pricing tiers. The practical effect is that many applications support SSO and SCIM in principle but only at licensing levels that small and mid-market organizations can't justify. This forces IT teams to either upgrade licensing, accept manual management, or use a provisioning platform that doesn't depend on the vendor's SCIM implementation.

Can an IGA platform provision users in applications that don't support SCIM?

Yes, through direct API integrations with the application's native API rather than through SCIM. IGA platforms maintain integration libraries that cover applications not in IdP SCIM galleries. For applications without any API, automated manual task routing — where the platform generates a tracked task for the application owner — keeps the manual step inside the workflow with an audit trail.

How does SSO-only provisioning differ from SCIM provisioning?

SSO handles authentication — whether a user can log in. It provides a deprovisioning signal when the IdP account is disabled (the user can no longer authenticate), but doesn't automatically create accounts for new users, manage application-specific role assignments, or trigger graceful offboarding actions like data transfer or license reclamation. SCIM handles the full lifecycle including creation, attribute updates, and deactivation. SSO without SCIM means manual onboarding and partial deprovisioning coverage.

What should MSPs recommend for clients with SaaS apps that can't be integrated via SSO or SCIM?

For applications where SSO and SCIM can be enabled through licensing or configuration, prioritize that work first. For applications where no integration path exists for any budget, either push governance responsibility to the business unit that owns the tool or include the application in a managed offboarding checklist with explicit ownership. An IGA platform with a broad API integration library reduces the size of the "manual" category without eliminating it entirely.

See How Zluri Handles the Non-SCIM Applications in Your Stack

Most organizations find that the automated portion of their SaaS stack covers the well-known applications and leaves a long tail of tools that require manual provisioning and deprovisioning. See how Zluri's API integration library and automated manual task routing handle both the automated and manual portions of that long tail.