S_USER_GRP — User Group Authorization for User Master Maintenance
S_USER_GRP controls create, change, display, lock/unlock and delete operations on user master records, scoped by the user group value stored on the target user's own record, not by any property of the administrator. A role can be perfectly configured and still fail if the target user's group field is blank or set to a value the admin was never authorized for.
This page covers what S_USER_GRP actually restricts in user master maintenance, the two fields it checks, and the transactions and APIs that fire the check. The bulk of the content is the tracing sequence for a failed check and the pitfalls that lead teams to blame the wrong object.
Reviewed by an ERPClimb SAP consultant on 16 Sept 2026· 924 words
What it protects
S_USER_GRP guards create, change, display, lock/unlock and delete operations on user master records, scoped by the user group field stored on the target user's Logon Data tab, not any role or CUA construct sharing a similar name. It is the object organizations use to split user administration duties, letting one team manage only users tagged with a particular group value while another team manages the rest. The structural fact that explains most confusion: the check is evaluated against the user group value stored on the record being maintained, not against any attribute of the administrator running the transaction, and not against the roles or profiles the target user holds. A correctly built S_USER_GRP authorization still fails outright if the target user's group field is empty or set to a value the administrator was never granted.
Fields checked
Two fields drive the check, and both must match for the action to succeed.
- ACTVT - the activity being performed: 01 create, 02 change, 03 display, 05 lock or unlock, 06 delete, 08 display change documents.
- CLASS - the user group value stored in the target user's own master record, maintained on the Logon Data tab as the user group for authorization check; the administrator's authorization must contain the same value that appears on the record actually being touched, not on the administrator's own record.
Where it is checked
The check fires at the point a user maintenance action is committed or a record is read, evaluated against the target record's group value each time.
- SU01 and SU01D single user maintenance - checked on save for whichever activity was invoked, and again on plain display with activity 03.
- SU10 mass user maintenance - checked once per user in the selected list, so a batch action can partially succeed and partially fail across a mixed population of user groups.
- User maintenance BAPIs used by provisioning tools and identity management connectors - the same object fires under the hood when accounts are created or changed programmatically.
- Central User Administration distribution - each child system re-evaluates its own S_USER_GRP authorization for the technical user distributing the change, independent of what was checked in the central system.
- Display-only helpdesk or audit access - reading a single user's data still triggers activity 03, so read-only roles need this object too, not just S_TCODE for the display transaction.
How to trace a failed check
Reproduce the failure, then open SU53 immediately, before running anything else, and look for an S_USER_GRP entry showing the CLASS value that was checked against what the administrator's role actually authorizes. If SU53 comes back empty or shows an unrelated object, which happens often with SU10 mass runs or background provisioning jobs where the failing check belongs to a different session, switch to the authorization trace transaction, repeat the action, and read the trace for the S_USER_GRP entry instead. Separately, open the target user's SU01 record on the Logon Data tab and read the user group field directly, since a blank or unexpected value there is frequently the real cause. Package for the security team: the administrator's user ID, the target user ID or list, the transaction or API used, the activity code attempted, and the CLASS value found on the target record. Do not report only 'access denied maintaining users' - the CLASS mismatch is the entire diagnosis.
Whose problem this is
This is security territory, since it governs segregation of duties in user administration itself. A useful request names the administrator's user ID, the target user or population, the specific activities needed (create, change, lock, delete, display), and the business reason for that group scope. If the target user's own group field is missing or wrong, that is a master data correction for whoever owns that user record, not a role change request.
Common pitfalls
Most failures trace back to a mismatch between what the role authorizes and what value actually sits on the target record, not to a broken role.
- Assuming S_TCODE access to SU01 is sufficient - the transaction opens fine but the save is blocked by S_USER_GRP, which looks like a display-only restriction but is not.
- Confusing this object with S_USER_AGR, S_USER_PRO or S_USER_TCD, which govern assigning roles, profiles or transaction authorizations to a user; a failed S_USER_GRP check on the maintenance action itself says nothing about whether role or profile assignment would also fail.
- The target user's group field left blank because it was never set when the account was created - an administrator correctly scoped to specific group values gets denied even though the requested access is entirely appropriate.
- Assuming a successful display of one user proves access works for all users - CLASS is evaluated per target record, so the same administrator can succeed on one user and fail on the next.
- In SU10 mass runs, a partial failure across the list is sometimes read as a data problem with the failed users rather than an authorization gap, because the job appears to complete instead of erroring out cleanly.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-auth-objects/s-user-grpERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.