One of the most persistent frustrations in IT is the gap between what management expects automated provisioning to cover and what is technically possible. The expectation: when someone is hired, every application they need is provisioned automatically. The reality: a significant portion of enterprise applications either do not support API-based provisioning, restrict it to higher-tier licensing tiers, or require native SSO configurations that the organization has not purchased.

The result is IT teams being held responsible for provisioning applications they cannot automate, troubleshooting applications they do not have admin access to, and fielding requests that expose a fundamental mismatch between organizational expectations and technical reality.

This is not primarily a tooling problem. It is an ownership and expectation problem. The right solution addresses both.

The Honest Map of What Applications Actually Support

Enterprise SaaS applications fall into roughly three categories when it comes to provisioning:

Well-integrated applications have robust APIs, support SCIM provisioning, and federate with major identity providers through SAML or OIDC. For these applications, automated provisioning and deprovisioning through an IGA platform or identity provider is straightforward. The major productivity suites, CRM platforms, and development tools tend to fall here.

Partially-integrated applications have APIs but restrict provisioning features to higher license tiers. The free or standard tier gives you the application. The enterprise tier gives you SCIM support and SSO. For organizations that have not purchased the higher tier, the API is technically available but practically inaccessible. The gap here is a licensing decision, not a technical limitation.

Non-integrated applications have no API, require manual admin console work to add or remove users, or are legacy systems that predate modern identity protocols. These applications can only be provisioned by someone with an admin account in the application itself.

The challenge is that managers requesting "automated provisioning for all applications" typically do not distinguish between these categories. From their perspective, the system should handle all of it. From IT's perspective, the constraint is real and the responsibility for non-integrated applications is often unclear.

The Two Problems That Need Separate Solutions

Problem one: no API means no automation. For applications without API access or SCIM support, automated provisioning is not possible through standard integration methods. This is a technical constraint, not an IT failure.

The workaround options are limited. Browser automation (sometimes called RPA-based integration) can interact with an application's web interface to perform provisioning actions, mimicking manual administrator clicks. This works for web-based applications that have predictable UI patterns, though it is more fragile than API integration and depends on the UI staying consistent. Zluri uses AI-powered browser automation as a fallback for applications that cannot be integrated through standard API methods, combining deterministic scripts with AI to handle UI changes.

For applications where even browser automation is impractical, the only realistic option is a structured manual process with clear ownership.

Problem two: no admin license means IT cannot do the work. When a department decides not to purchase an admin license for IT (usually to save money on licensing tiers), IT cannot provision users in that application even manually. Asking IT to provision an application they cannot log into is asking them to do something structurally impossible.

The solution to this problem is not technical. It is organizational: the department that owns the application and holds the admin license needs to own the provisioning responsibility for that application.

The App Owner Model: Getting the Work to the Right Person

The mechanism that resolves the "IT does not have admin access" problem is formal app ownership assignment. For each application in the organization's stack, there should be a designated owner who has the admin access and the organizational responsibility to provision and deprovision users.

For well-integrated applications where provisioning can be automated, the app owner is a governance designation: they approve access requests and certify access during reviews, but the provisioning itself runs automatically.

For non-integrated applications or applications where IT lacks admin access, the app owner is the fulfillment owner: when a new hire needs access to the application, the task goes to the app owner, not to IT.

In Zluri, this is implemented through what the platform calls manual tasks with fallback assignment. When an onboarding playbook runs and reaches a step for an application that cannot be automated, Zluri generates a structured manual task assigned to the designated app owner. The task contains the new hire's details, the access level required, and a due date. The app owner receives a notification in Slack or email, provisions the user manually in the application, and marks the task complete. The completion is logged in the audit trail.

This shifts the conversation with management from "IT cannot automate this application" to "the department that owns this application is responsible for provisioning it, and here is the workflow that ensures it gets done and tracked." IT maintains visibility and audit trail without being the bottleneck for applications they cannot administer.

Making the Expectation Gap Visible

Part of the persistent frustration in this situation is that the expectation gap is invisible to management. When IT says "that application does not support automated provisioning," management hears a technical excuse rather than a genuine constraint.

Making the constraint visible and actionable changes the conversation. An application catalog that distinguishes between "automated provisioning" and "manual provisioning with designated owner" makes the distinction concrete. When management can see that 60 percent of applications provision automatically on day one and 40 percent require a manual step by the department owner, the expectation becomes calibrated to reality.

Zluri's App Catalog surfaces this distinction. Applications with direct API integration provision automatically when a playbook runs. Applications designated as manual provisioning generate a task to the app owner. The onboarding workflow completes, the audit trail shows both automated and manual steps, and the status of each application's provisioning is visible without IT having to chase departments for confirmation.

Self-Serve Requests for Access Outside Standard Provisioning

Not all access needs are captured in the onboarding playbook. A new hire might need access to an application that is not part of their standard role. An existing employee might need temporary access to a tool for a specific project.

The right mechanism for these cases is a self-service request workflow: the employee or their manager submits a request through a structured channel (a web catalog or a Slack command), the request routes to the designated app owner or manager for approval, and once approved, either the provisioning runs automatically (for API-integrated applications) or a manual task is generated for the app owner.

This removes IT from the middle of routine access requests entirely. The request goes to the person with the authority and the technical access to fulfill it. IT maintains the governance infrastructure (the catalog, the approval workflows, the audit trail) without being the execution layer for applications they cannot administer.

What IT Actually Needs to Manage This Well

The practical requirements for a sustainable approach to mixed-integration environments:

A complete application inventory that distinguishes between automated, semi-automated, and manual provisioning. This is the foundation for setting accurate expectations.

Clear app owner assignments for every application, with the organizational backing that makes ownership meaningful. The app owner designation should be documented and the person should understand that they are responsible for fulfillment when manual provisioning is required.

A structured manual task workflow that assigns, tracks, and records completion for manual provisioning steps. A Slack message is not a workflow. A formal task with a due date, a completion requirement, and an audit log entry is.

Separation between IT as governance owner and IT as execution layer. IT should own the governance infrastructure (the provisioning rules, the app catalog, the audit trail). IT should not be the execution layer for applications where they do not have admin access.

Escalation visibility when manual tasks are not completed. If an app owner does not provision a new hire's access within the defined SLA, someone should know. Automated reminders and escalation notifications are the mechanism.

The Broader Principle

The frustration the Reddit OP described is real and common. The framing that helps address it is: IT's role in provisioning is to automate what can be automated, structure what cannot be automated, and ensure the work gets to the right person when IT is not that person.

That framing gives IT a defensible position when management pushes back. "We cannot automate this application because it does not have an API" is a statement about a technical constraint. "We have set up a workflow that assigns provisioning for this application to your department's designated owner, with automated reminders and an audit trail" is a statement about a solution.

The solution does not require every application to have an API. It requires every application to have a clear owner and a structured process for the work that cannot be automated.