SU3 — Maintain Own User Data

SU3 opens a maintenance screen scoped entirely to the logged-on user's own master record. It has three working tabs: Address, for name and communication data; Defaults, for decimal notation, date format, logon language, time zone, spool device and start menu; and Parameters, for personal SPA/GPA parameter ID and value pairs that feed default values into transaction screens. In older releases a Roles tab existed for display only. The structural fact that explains most confusion is that SU3 has no user-ID input field at all — it is hard-wired to whoever is logged in, so it cannot be used by an administrator to change someone else's data, and a user cannot use it to grant themselves a role or profile. That boundary belongs to SU01.

End users reach for SU3 to set their preferred date format, decimal notation, printer, start transaction, or logon language without raising a ticket. Consultants reach for it during testing to plant a parameter ID value that changes a default field on a transaction screen — for example defaulting a plant, purchasing organization or sales area so a test script does not require re-entry every run. It also comes up when diagnosing why a transaction pre-fills an unexpected value: the answer is often sitting in that user's Parameters tab rather than in configuration. In S/4HANA the same needs are partly covered by Fiori launchpad personal settings, but backend defaults consumed by classic transactions still live in SU3.

To confirm a wrong default is coming from SU3, open USR05 in SE16N filtered on the user's BNAME and the specific PARID, and check the PARVA value stored. If the address looks wrong, get PERSNUMBER from USR21 for that BNAME, then look up the same PERSNUMBER in ADRP to see the address record actually feeding the Address tab. A mismatch between what SU3 displays and what USR05 or ADRP holds usually points to caching or to central address maintenance overriding the local value.

SU3 is unchanged in S/4HANA and remains the backend transaction for a user's address, defaults and parameters. The Fiori launchpad provides its own personal settings app covering some of the same ground — date format, decimal notation, time zone — for launchpad-rendered apps. The two are not always in sync: a user can have one value in SU3 and a different one applied inside Fiori tiles, which is worth checking when a default behaves differently in classic GUI versus Fiori for the same user.

Functional territory for defaults and parameter values used in testing or process configuration; basis or security territory when the question involves CUA distribution, central address maintenance, or why a field is locked. A clean handover states the user ID, the exact Parameter ID or Defaults field involved, the value expected versus the value observed, and whether the user is CUA-managed.

SU01 is the next step for anything SU3 cannot do — changing another user's data, assigning roles, or resetting a password. SUIM is useful for reporting across many users' parameter values or role assignments when a single SU3 check is not enough. PFCG is where the roles a user actually holds are maintained, which SU3 will never show as editable. Reading SU01 after SU3 clarifies the boundary between self-service and administrative user maintenance.