BAPI_USER_CREATE1 — BAPI for Creating an SAP User Master Record

BAPI_USER_CREATE1 creates a new user master record in the system, the same object maintained interactively through SU01. It writes logon data, password, validity period, address and communication data, and can attach initial roles, profiles, or parameter values in the same call. It is the standard programmatic entry point used by provisioning scripts, migration loads, and identity management middleware to create SAP users without a GUI session. It does not perform authorization checks against the calling user's own role scope in the way SU01 does when a security administrator is restricted to certain user groups, so calling it from a technical user with broad authority bypasses that control layer entirely if the wrapper program does not reimplement it.

The interface separates single-value import parameters from table parameters carrying multiple assignments.

BAPI_USER_CREATE1 does not commit the database update on its own. The user record is built inside the current LUW and only becomes persistent after the caller executes an explicit commit, typically the standard transaction-commit BAPI, immediately after checking RETURN. If the caller forgets the commit, the call appears to succeed — no dump, no error message, RETURN can even show only informational lines — but the user vanishes at the end of the session because the update is rolled back with everything else in the LUW. This is a frequent cause of the 'the migration log says the user was created but it does not exist in SU01' complaint, and it is almost always a missing commit rather than a BAPI defect.

RETURN is a table, not a single status flag, and the call's own SY-SUBRC is not a reliable success indicator because RFC-enabled BAPIs generally return 0 regardless of business-level failure. The only correct check is to loop over RETURN and test the TYPE field of every line for 'E' or 'A'. A common defect is checking only the first line, or checking whether the table is initial — both miss real errors, because BAPI_USER_CREATE1 frequently returns one or more informational 'S' messages (password generated, license type defaulted, communication type defaulted) alongside a genuine error further down the table, such as a duplicate username or a password policy violation. Interfaces that treat 'RETURN is not empty' as failure abort on harmless informational noise; interfaces that treat 'no dump occurred' as success commit half-built users with no password or no role. Both patterns show up in production as users who exist but cannot log on, or as duplicate-key errors on a second run against a user that was actually never committed.

BAPI_USER_CREATE1 remains valid and in active use on S/4HANA for on-premise systems; there is no released Fiori app or OData service that fully replaces custom ABAP-driven user provisioning at this level of detail. Enterprises moving to cloud-based identity provisioning (external identity access governance tooling or cloud identity services) increasingly push user lifecycle events through those platforms instead of calling this BAPI directly, but the underlying user master creation on the ABAP system still ultimately routes through the same mechanisms this BAPI wraps. For custom interfaces and migration cockpits built in-house, it is still the recommended call.

Failures cluster around a small set of causes, almost all traceable to interface design rather than the BAPI itself.

Failure to create or commit is a developer problem: the fix is in the calling program's return-loop logic and commit sequencing, and evidence needed is the full RETURN table content, not just a success or failure flag. Failure of the resulting user to work correctly — wrong roles, wrong license type, wrong validity — is a security team problem, and the developer needs the exact role and profile list the security team expected to be assigned.

Mirrors the interactive transaction SU01 and reads back through BAPI_USER_GET_DETAIL for verification after creation. Subsequent maintenance of the same record, including password resets and role changes, goes through BAPI_USER_CHANGE rather than a second call to this BAPI. Underlying data lands in the standard user master tables including the logon data table and the role assignment table, which is where a mismatch between what the BAPI reported and what actually persisted can be confirmed directly.