The Provisioning Hell Index: Ranking the 10 Most Painful Apps to Provision

TL;DR

The apps that run your business are the apps that break your IT team.

We ranked the 10 most painful enterprise apps to provision. SAP scores a perfect 10/10 on the hell scale - 2-4 hours per user, thousands of authorization objects, requires a specialized career path to navigate. Epic requires weeks of certification training before you're allowed to touch security. Workday has an "activation trap" where hours of configuration remain dormant because you forgot to click one button.

These aren't apps missing SCIM. They have sophisticated permission systems - systems so complex they've become unmanageable. The same compliance requirements that protect your business created permission structures that require specialized training to configure correctly.

*Hours if custom roles needed.

The Hell Score methodology

We ranked enterprise applications on a 1-10 scale based on:

• Time to provision a complex user (not a basic account - someone who needs real access)
• Number of discrete permission decisions required
• Learning curve for administrators
• Frequency of "silent failures" where access looks correct but doesn't work

A score of 1 means single-click provisioning (invite email, assign role, done). A score of 10 means maximum entropy - hours of configuration, specialized training required, frequent debugging cycles.

For comparison: Slack scores about 1.5. Notion scores about 2.

The provisioning hell index

#1: SAP S/4HANA (10/10)

The undisputed champion of provisioning complexity.

SAP doesn't have permissions. It has a language of authorization that requires a specialized career path to navigate. The system contains thousands of "authorization objects" - granular permission units that control access to specific transactions. A single role can contain dozens of these objects, each with multiple field values that must be configured correctly.

The numbers

• 2-4 hours to provision a complex user
• Thousands of possible transactions, each with its own permissions
• 150+ authorization profiles possible per user (hard system limit)
• Requires dedicated "SAP Security" specialists

The pain

When a user gets "Access Denied," you can't just look at a checkbox. You run a system trace to capture which specific authorization object failed, find the role containing that object, manually add the missing value, regenerate the profile, and perform a user comparison. Then repeat when the next error appears.

IT admin quote: "The SAP system itself is inherently complex, with thousands of possible transactions, each with its own set of permissions." - Voquz Labs on SAP authorizations

#2: Workday (9.5/10)

The activation trap.

Workday separates "Domain Security" (access to data) from "Business Process Security" (access to actions). A user might see data but be unable to act on it, or vice versa. Setting up an integration user requires manually adding Get and Put access to dozens of specific domains.

The numbers

• 45-60 minutes per integration user
• 100+ domain security iterations for complex setups
• Requires running "Activate Pending Security Policy Changes" after every edit

The pain

The activation trap is lethal. After painstakingly configuring 50 domains, the changes aren't live until you run a specific activation task. If you forget, hours of configuration remain dormant. API calls fail with 403 errors, but the setup screens look correct. This is the most common point of failure for new admins.

IT admin quote: "I'm staring down 100+ iterations of intersection security... I'm doom-scrolling on this SOW spreadsheet wondering what the eff to do. Either way, it's a ton of work!"

#3: Epic Systems (9.2/10)

You need certification to add a user.

Epic powers healthcare records for hundreds of millions of patients. Its security architecture is designed for life-and-death scenarios, resulting in redundancy and override systems that only certified administrators can navigate.

The numbers

• 1-2 hours per complex user
• Requires formal Epic certification training (often weeks in Verona, WI)
• Security defined at 6+ hierarchical levels (System > Service Area > Location > Department > Template > User)
• Thousands of numbered "Security Points" controlling specific functions

The pain

A nurse can't see a tool in the Emergency Room that she could see in the ICU. Troubleshooting requires analyzing "Build Comparison" and "Menu Summary" tools to trace which level of the hierarchy is winning. Epic certification is mandatory - this isn't something you can pick up on the job.

IT admin quote: "Check her department role overrides and verify they are working as intended. Check her Stork security class to verify that she has access to these tools." - Epic analyst troubleshooting a user profile

#4: Oracle ERP Cloud (8.8/10)

Locked down by design.

Oracle provides "seeded roles" out of the box - but since Release 12, these roles are locked to ensure "upgrade safety." You cannot modify them. You must clone them to customize, forcing administrators to maintain a parallel universe of custom roles that drift from the standard.

The numbers

• 30-90 minutes per user
• Roles locked down, must clone to customize
• Data security requires separate "Manage Data Access" configuration
• Debugging often requires diving into EL Expressions embedded in menu structures

The pain

The Security Console UI looks modern, but finding why a menu item is hidden often requires digging into Expression Language logic that isn't visible in the standard role view. Assigning a role is insufficient - you must also assign "Data Access" via a separate screen.

#5: Salesforce (8.5/10)

The permission set explosion.

Salesforce is mid-transition from Profiles (one per user) to Permission Sets (many per user). The result is a hybrid environment where legacy and modern architectures collide, creating a matrix of permissions that can change overnight.

The numbers

• 15-30 minutes for standard users; hours for custom roles
• 200+ possible settings per user
• Profiles, Permission Sets, Permission Set Groups, and "Muting Permission Sets" all interact

The pain

Permission Sets are strictly additive - you can't deny access. So Salesforce introduced "Muting Permission Sets" to turn off permissions inherited from other sets. This double-negative logic (adding a permission to mute a permission) is cognitively taxing. And the interaction between Sharing Rules, Role Hierarchy, and Object Permissions means debugging "why can't I see this record?" requires checking five systems simultaneously.

IT admin quote: "Am I drunk, or 525 permissions change themselves???" - Salesforce admin discovering overnight permission changes

#6:

Hundreds of permissions, no hierarchy.

NetSuite's permission model divides access strictly into categories (Transactions, Reports, Lists, Setup) with no inheritance between them. Each role requires manually configuring dozens of individual permissions.

The numbers

• 20-45 minutes per user
• 100+ permission types out of the box
• Roles multiply with organizational complexity (per subsidiary, per department)

The pain

Access isn't just about permissions - it's about Forms. If a user has permission to data but the Form hides the field, they can't see it. Debugging requires checking role permissions, record types, form layouts, and hidden divider sections.

IT admin quote: "Our specialists are knowledgeable across the hundreds of permissions within Oracle NetSuite and the risks if roles are designed ineffectively." - PwC advisory

#7: Jira (7.5/10)

Scheme sprawl.

A Jira project doesn't have permissions - it's associated with a Permission Scheme shared across projects. Changing one project can break ten others.

The numbers

• Permission Schemes, Issue Security Schemes, and Notification Schemes all interact
• "Scheme sprawl" leads to hundreds of unmanaged schemes
• Team Managed vs Company Managed projects have completely different models

The pain

A user might have the "Trusted" badge, belong to jira-administrators, and be a "Project Admin" - yet still can't create a Sprint because they lack "Manage Sprints" in the underlying board filter query.

IT admin quote: "I've noticed how egregiously over-engineered the permissions functions are. Like you have jira admin, site admin, role admin, board admin, project admin, and it's all turbo customizable... chill guys."

#8: Cerner Millennium (7.2/10)

The vendor ecosystem.

Cerner's complexity is environmental. Provisioning a user requires synchronization across 20+ vendor sub-systems - HNA User ID, Citrix account, Imprivata profile for badge authentication. If one system doesn't match, the user can't log in even if their Cerner account is perfect.

The numbers

• 30-60 minutes per user
• Privilege levels (0-3) reflect legacy database access concepts
• "Cerner is responsible" vs "Client is responsible" dynamic slows troubleshooting

#9:

The granularity trap.

Procore's "Standard" permission level is insufficient for real-world workflows, forcing admins to either grant "Admin" rights or create complex granular overrides.

The numbers

• Permission Templates per project
• Secondary layer of task-based checkboxes overrides the primary levels
• Dozens of highly specific templates (e.g., "Foreman - No Budget Access - Can Upload Photos - No Delete")

#10:

Triple lock security.

Used for legal eDiscovery where showing a document to opposing counsel is catastrophic. Permissions are nested three levels deep: Tab visibility, Object security, and Item-level security. Miss any one and the data is invisible.

What these apps have in common

Decades of legacy. Most of these apps (SAP, Oracle, Epic, Cerner) have core architectures dating back 20-40 years. Instead of redesigning security, they layered features on top of features.

Compliance requirements. SAP's separation of Create vs Change permissions is mandated by SOX. Epic's hierarchical security ensures providers can't order medications outside their authorized facility - a HIPAA and patient safety requirement. The complexity is the price of compliance.

No unified role hierarchy. Instead of one role that encapsulates a job, admins manage multiple pieces (responsibilities in Oracle, security classes in Epic, schemes in Jira). Without inheritance, admins manually maintain individual permissions per user.

Role sprawl. Organizations accumulate hundreds of roles because creating a new specific role was easier than refactoring existing ones. The older the deployment, the more byzantine the permission structure.

Specialized knowledge. SAP security is a career specialty. Epic requires formal certification. These aren't systems a general IT admin can safely configure - they require training that costs thousands of dollars and weeks of time.

The comparison: hell vs normal

For context, here's what provisioning looks like in "normal" modern apps:

Slack's entire permission model fits in a single help article. SAP's requires multiple volumes.

In Slack, provisioning is "invite and assign." In SAP, provisioning is "identify roles, copy to custom namespace, debug authorization objects, run trace analysis, fix errors, generate profile, perform user comparison, then iterate when the next error appears."

What this means for IT

If you manage identity for a company running these systems, you're not doing "user administration." You're doing specialized engineering work that requires domain expertise, compliance knowledge, and often formal certification.

The irony: these are often your most critical systems. The ERP that runs your finances. The EHR that manages patient care. The CRM that holds your customer relationships. The apps you absolutely cannot walk away from are the apps that require the most effort to provision.

And most of them will never have simple SCIM. SAP's complexity isn't a bug - it's the accumulated weight of 40 years of compliance requirements. Epic's security isn't going to simplify - patient safety demands granular control. The permission structures exist because the business requires them.

The question isn't whether these apps will get easier. They won't. The question is how you manage provisioning at scale when each user requires hours of specialized configuration.

The alternative

Stitchflow delivers SCIM-level provisioning through resilient browser automation, backed by 24/7 human in the loop. We build the integration. We maintain it. <$5K/app/year.

For the apps on this list - the ones with byzantine permission structures that will never simplify - we map the complexity once. You assign groups in Okta. The right permissions apply automatically.

Your SAP security specialist shouldn't spend 4 hours per user. Your Epic analyst shouldn't debug hierarchy overrides for every new physician. The complexity exists for good reasons - but you shouldn't have to navigate it manually, every time, for every user.