BAPI_USER_CHANGE — BAPI_USER_CHANGE for updating user master records

BAPI_USER_CHANGE acts on the user master record stored across the USR* tables (USR02, USR04, USR21, ADRP and related address tables) and mirrors what a Basis administrator does in SU01 change mode. A caller passes the username plus one or more structures carrying the fields to update: logon data, address, defaults, password. It is used from external identity management systems, HR integration middleware, and custom mass-maintenance reports where SU01 itself is not scriptable. It does not create the user record, does not by itself assign roles, profiles, or activity groups, and does not touch the authorization buffer directly. Those are separate steps handled by sibling BAPIs or by the standard buffer refresh that follows any user master change.

The interface separates data structures from change-indicator structures, so only the fields actually flagged are written; anything passed in the data structure but not flagged is silently ignored.

Like every classic BAPI, BAPI_USER_CHANGE does not commit its own work. It updates the user buffer and database tables within the current LUW but leaves the commit to the caller. A follow-up call to BAPI_TRANSACTION_COMMIT (or the equivalent COMMIT WORK inside an ABAP program) is required to make the change durable. If the caller forgets this, the change appears to succeed at the interface level, RETURN comes back clean, but the update is rolled back at the end of the calling program or dialog step and the user master looks untouched on the next read. This is the single most common false-positive in scripted mass changes: the log says success, the system says nothing happened.

RETURN is a table, not a single flag, and SY-SUBRC after the call is not reliable evidence of anything because classic BAPIs return control cleanly even when the business logic rejected the request. The only correct check is scanning RETURN for entries with TYPE equal to E or A; a TYPE S or I entry, or an empty table, indicates the change went through. A frequent interface bug is checking only whether RETURN is initial and treating that as success, which misses cases where the BAPI returns a single warning-level entry that is actually informational and harmless, or conversely stops processing entirely on the first E-type row without reading MESSAGE or MESSAGE_V1 through V4 to get the actual field-level cause. Batch integrations that loop over thousands of users need to capture the full RETURN table per user, not just the first row, because password policy violations, locked-user conflicts and validity-date errors can appear as separate messages in the same call.

BAPI_USER_CHANGE remains valid and in active use on S/4HANA; there is no announced replacement that supersedes it for straightforward user master updates. Larger organizations increasingly route user lifecycle changes through identity provisioning tools or a central user administration layer rather than calling this BAPI directly from custom code, but where a direct API call is still required this is the one used. Role and profile assignment continues to sit outside this BAPI regardless of release.

Most production incidents trace back to one of a small set of causes.

This sits with the security or Basis team, since it touches the user master record directly. When a caller reports the BAPI failed, they need to hand over the exact RETURN table content and the username involved, not just a screenshot of an interface log stating error. The security team confirms whether the rejection is policy-driven, such as password rules or validity windows, before any code fix is considered.

The transaction it mirrors is SU01 in change mode. The underlying tables are USR02, USR04 and USR21 plus the linked address tables. The natural sibling for creating a new user is BAPI_USER_CREATE1, and for reading current values before deciding what to change, BAPI_USER_GET_DETAIL is the standard pre-check call used to avoid overwriting fields unintentionally.