This Is What Provisioning a User Actually Looks Like

TL;DR

Some apps require 17 steps and 4 hours to add one user. That's not administration - that's a workflow begging to be automated.

We documented exactly what it takes to provision users in SAP, Epic, and Viewpoint Vista - three of the most complex enterprise systems. The walkthroughs below show every step: the authorization objects, the security traces, the debug cycles, the escalations to DBAs.

This isn't theoretical. This is what your IT team actually does, repeatedly, for every new hire who needs access to these systems. When you see the steps laid out, the case for automation makes itself.

Stitchflow handles this complexity so you don't have to. We navigate the authorization trees, configure the security points, handle the debugging cycles. You assign groups in Okta. Users get access. <$5K/app/year.

What we're showing you

The systems below are among the most painful to provision. They're also often the most critical - the ERP that runs your finances, the EHR that manages patient care, the construction management system that tracks your projects.

These walkthroughs are synthesized from technical documentation, admin guides, and IT practitioner accounts. They represent what provisioning actually looks like when there's no automation.

Adding a Financial Analyst to SAP

Alice joins as a Financial Analyst in Accounts Payable. Here's what IT does to give her access.

Step 1: Gather requirements

Consult the role catalog (if one exists) or talk to the AP department to determine which transactions Alice needs. AP Analysts typically get role Z_AP_CLERK. But Alice is senior and needs reporting access, so she also needs Z_AP_REPORT. Identify all relevant roles upfront.

Step 2: Create user account

Open SAP GUI. Navigate to transaction SU01. Enter a new user ID. Fill out name, email, department. Set an initial password.

Step 3: Assign roles

On the Roles tab, assign Z_AP_CLERK and Z_AP_REPORT. If Alice needs access to multiple company codes, assign separate roles for each (Z_AP_CLERK_NA for North America, Z_AP_CLERK_EU for Europe).

Step 4: Check authorization profiles

Each role has authorization profiles behind it. Open transaction PFCG (Role Maintenance). The standard AP Clerk role doesn't allow a transaction Alice needs. Options:

• Modify the existing role (risky - affects all users with that role)
• Copy the role to a new custom role (Z_AP_CLERK_ALICE), edit authorization data, save

Step 5: Configure authorization objects

Inside PFCG, navigate the authorization tree. Each node represents an authorization object with specific fields. For example, to allow posting vendor invoices:

• Find authorization object F_BKPF_BUK (Accounting Document: Authorization for Company Codes)
• Set field ACTVT to 01 (Create), 02 (Change), or 03 (Display)
• Set field BUKRS to the specific company code values Alice should access
• Repeat for every authorization object in the role

The tree shows traffic lights:

• Red = missing values (cannot proceed)
• Yellow = partially maintained
• Green = complete

You cannot save until everything is green.

Step 6: Generate the profile

Click the Generate button to create the authorization profile. This writes the configuration to the database. The role is useless until this step is complete.

Step 7: Assign and compare

Back in SU01, add the role to Alice's account. Run "User Comparison" to push the profile to her user master record.

Step 8: Test

Alice logs in. She tries to approve a vendor invoice. Error: "You are not authorized to use transaction MIR4."

Step 9: Debug

Run transaction SU53 to see the last authorization check failure. It shows:

```
Authorization object: M_RECH_WRK
Field: ACTVT = 02
Field: WERKS = 1030
Result: NO AUTHORIZATION
```

Alice is missing authorization for Plant 1030 on the invoice approval object.

Step 10: Fix

Find the role containing M_RECH_WRK. Open in PFCG. Navigate to that authorization object. Add value 1030 to field WERKS. Regenerate the profile. Run user comparison.

Step 11: Test again

Alice tries again. This time she can approve invoices - but she can't run the AP aging report. New error.

Step 12: Debug again

Run SU53. Different authorization object, different missing value. Find the role, add the value, regenerate, compare.

Step 13-17: Repeat

Over Alice's first week, 3-5 more authorization errors surface. Each requires the same cycle: trace, identify, find role, edit, regenerate, compare, test.

Total time: 3-4 hours spread over several days. If formal change management is required (common in SAP shops), each role change needs approval and transport, extending the timeline to a week or more.

Adding a Doctor to Epic

Dr. Chen joins as a cardiologist who will also supervise residents. Here's what the Epic analyst does.

Step 1: Create user record

Open Epic Hyperspace. Navigate to the Security module. Create a User record with Dr. Chen's personal info, NPI (National Provider Identifier), and credentials. Link her user record to her Provider record (SER) so Epic knows this is a physician who can place orders.

Step 2: Select security template

The hospital has pre-defined templates. For a cardiologist, select "Attending Physician - Cardiology." This template brings a set of Security Classes:

• ClinDoc Physician (can document in charts)
• Orders Physician (can place orders)
• Inbasket Physician (message and results handling)
• Plus 10-15 other classes depending on hospital configuration

Step 3: Configure department access

Grant Dr. Chen access to the Cardiology department and related units (ICU, Cath Lab). Check boxes for each nursing unit and clinic location where she'll see patients.

Step 4: Adjust security points

By default, residents cannot sign orders without cosign. But Dr. Chen is an attending. Find the security point for "Pend/Sign orders without cosign required" and enable it. If the template didn't handle this, manually adjust her security class.

Step 5: Enable supervisory functions

Dr. Chen will supervise residents, so she needs to cosign their notes and orders. Verify that "cosign others' documentation" is enabled in her security configuration.

Step 6: Link hierarchy levels

Epic security is defined at 6 levels: System Definitions > Service Area > Location > Department > Security Class > User. A setting at the Department level overrides the System level. A User level setting overrides everything. Make sure Dr. Chen's settings are at the right level so they don't get unexpectedly overridden.

Step 7: Test

Dr. Chen logs in. She opens a test patient chart, writes a note, places a medication order, signs it.

The medication order fails. "Not authorized for restricted substance prescribing."

Step 8: Debug

Check her security classes. She's missing the "Controlled Substances" security class that allows prescribing Schedule II medications. Cardiologists often need this for pain management.

Step 9: Add security class

Navigate back to her user profile. Add the Controlled Substances security class. This class has its own set of security points that must be configured (DEA number linkage, prescribing limits).

Step 10: Verify compiled profile

Epic uses "compiled profiles" - the final access is calculated from the intersection of all hierarchy levels. Run the "Build Comparison" tool to verify Dr. Chen's compiled access matches what's intended. If something looks wrong, trace which level is overriding.

Step 11: Test again

Dr. Chen tries the controlled substance order. It works. But now she reports that a tool she needs (Pregnancy Wheel) appears in the Emergency Department but not in Cardiology.

Step 12: Debug hierarchy

The Pregnancy Wheel tool is enabled at the Department level for ED but not for Cardiology. Decide: should it be enabled for all of Cardiology, or just for Dr. Chen? If just her, add a user-level override. If all cardiologists, modify the department configuration.

Step 13: Coordinate

Changes to department-level configuration require approval from the Cardiology department head and possibly the Chief Medical Information Officer. Submit the request. Wait for approval. Implement.

Total time: 1-2 hours of direct configuration, plus several days of back-and-forth as access issues surface during Dr. Chen's first week on the job.

Adding a Project Manager to Viewpoint Vista

Bob joins as a Project Manager at a construction company running Vista. Here's what happens.

Step 1: Active Directory setup

Ensure Bob has an AD account. If Vista uses Windows authentication, add Bob to the "Vista Users" AD security group.

Step 2: SQL Server setup

On the SQL Server, add Bob's AD account as a login. Map basic read access. Or add him to an existing database role for Vista users.

Step 3: Create user in Vista

Open the VA User Profile screen. Enter Bob's info, assign a User ID. Select the "Project Manager" security role - this should grant access to Job Cost, Billing, and Project Management modules but not HR or full Accounting.

Step 4: Grant application access

Check boxes for each module Bob needs:

• Project Management: Yes
• Job Cost: Yes
• Accounts Payable: View Only
• Payroll: No
• General Ledger: No

Step 5: Database owner rights

Bob needs to run certain reports that require database-level access. Click "Grant DBO" to make him a database owner on the SQL backend.

Error: "Failed to grant DBO. Contact support."

Step 6: Escalate to DBA

The IT admin doesn't have permission to grant DBO. Escalate to the database administrator. Or open a support ticket with the vendor.

Wait.

Step 7: DBA grants access

The DBA manually runs:
```sql
ALTER ROLE db_owner ADD MEMBER [DOMAIN\Bob]
```

Step 8: Test

Bob logs in. He can see the Job Cost module. He opens a project, tries to enter a change order.

Error: "Access denied to Change Order Entry screen."

Step 9: Debug

The "Project Manager" role doesn't include Change Order Entry by default. Find the screen in Vista's security configuration. Either add it to the Project Manager role (affects all PMs) or create a custom role for Bob.

Step 10: Modify role

Add Change Order Entry to the Project Manager role. Save. Bob logs out and back in.

Step 11: Test again

Bob can enter change orders. But he tries to approve an invoice and gets another access error.

Step 12: Repeat

AP Invoice approval isn't in his role. Add it. Test again. Another screen is missing. Add it.

Total time: 30 minutes if everything works. 2+ hours if DBO grant fails or multiple screens need to be added. If vendor support is involved, could extend to next business day.

This is why automation matters

Three systems. Three new hires. Roughly 8 hours of IT time - and that's assuming things go relatively smoothly.

Now multiply by your actual headcount. A 500-person company with normal turnover (15%) has 75 new hires per year. If even a fraction of them need access to systems like these, you're looking at hundreds of hours spent navigating authorization trees, running traces, debugging access failures, and waiting for DBA escalations.

These systems aren't going to simplify. SAP's complexity exists because SOX compliance requires it. Epic's hierarchy exists because patient safety demands it. The permission structures are there for good reasons - but that doesn't mean your team should navigate them manually, over and over, for every user.

Stitchflow handles this

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 SAP, Epic, Vista, and systems like them - we navigate the authorization trees, configure the security points, handle the debugging cycles. You assign groups in Okta. Users get access.

Your SAP security specialist shouldn't spend 4 hours per new hire tracing authorization failures. Your Epic analyst shouldn't debug hierarchy overrides every time a doctor can't see a tool.

We do this so you don't have to.