S_USER_PRO — Authorization Profile Maintenance Object
S_USER_PRO controls creating, changing, displaying, deleting or activating authorization profiles, including the profile PFCG generates behind the scenes when a role is saved. Having full rights to build a role in PFCG does not automatically grant rights over the resulting profile object, which is why generation can fail even when the role itself looks complete.
This page covers S_USER_PRO, the object that guards profile-level maintenance rather than role-level maintenance. It focuses on why PFCG generation failures trace back to this object even when every other role-build authorization looks correct, and how to isolate that failure from the more commonly suspected S_USER_AGR or S_USER_AUT checks.
Reviewed by an ERPClimb SAP consultant on 16 Sept 2026· 832 words
What it protects
S_USER_PRO governs the profile object itself: the low-level container of authorization values that sits underneath a role, whether built manually through legacy profile maintenance or generated automatically by PFCG. The structural fact that causes most confusion is that role maintenance and profile maintenance are two separate authorization checks layered on top of each other. Rights in S_USER_AGR let someone open, edit and save a role in PFCG, but the final step of that save is a call into profile maintenance to write or activate the generated profile, and that call is checked against S_USER_PRO independently. A user can pass every check on the Authorizations tab, click generate, and still fail, because the profile name being written falls outside what S_USER_PRO permits for that user.
Fields checked
- PROFPAT - the profile name or name pattern being created, changed, displayed, deleted or activated, usually expressed as a wildcard range that mirrors a naming convention such as a Z or Y prefix.
- ACTVT - the activity being performed against the profile: 01 create, 02 change, 03 display, 06 delete, 08 activate or generate. Generation from PFCG typically requests 02 and 08 together.
Where it is checked
- PFCG - at the moment a role is generated or regenerated, when the system writes the profile that PFCG derives from the role's technical name; this happens on the Authorizations tab even though the visible screen is role-centric, not profile-centric.
- SU02 and SU03 - the legacy manual profile maintenance transactions, still used in some landscapes to inspect or hand-edit profiles outside PFCG.
- Mass or background profile generation jobs, such as scheduled regeneration runs after an authorization mass change, where the check runs once per profile in the batch.
- Profile-related steps during role transport post-processing on the target system, where activation of the transported profile triggers the same check.
How to trace a failed check
Reproduce the failure and immediately run SU53 for the affected user, but treat it as a first look only: SU53 shows the last failed check, and if anything else failed after the S_USER_PRO check it will overwrite the view. Follow up with the authorization trace (STAUTHTRACE, or ST01 on older releases) filtered to the user id and the time window of the attempt, and read the trace for the exact object S_USER_PRO, the ACTVT value requested, and the profile name pattern that was checked against. That profile name is the key piece of evidence: compare it to the naming convention the role was built under, because a mismatch there is the usual root cause. Hand the security team the user id, the technical role name (not the description), the derived profile name if visible in the trace, the activity code, and the transaction or job that triggered generation. Do not ask for S_USER_PRO to be widened to a full wildcard; ask for the specific naming range to be added, since a blanket grant defeats the purpose of restricting who can write profiles at all.
Whose problem this is
This is a security team object, not a functional one. Profile maintenance is infrastructure, and broad S_USER_PRO access is one of the more dangerous grants in a system because it touches the authorization layer itself. A good request names the exact profile naming pattern needed, the activities required (typically create, change, display, activate), and the business justification for why this particular user needs to generate profiles rather than routing the request through a role owner.
Common pitfalls
- A role passes every visible check in PFCG's Authorizations tab and still fails on generation, because the missing object is S_USER_PRO for the resulting profile, not anything on the role itself; people chase S_USER_AGR or S_USER_TCD first and waste time there.
- The profile name pattern granted does not match the actual naming convention in use, especially after a naming convention change mid-project; old patterns remain authorized while new role prefixes are silently blocked.
- Case sensitivity and wildcard placement in the granted pattern do not match the generated profile name exactly, so a pattern that looks correct at a glance still rejects the specific profile.
- Developers or consultants with SAP_ALL-equivalent access in a development system never see the restriction, so the first failure surfaces only in QA or production, where it is mistaken for an environment defect rather than a missing authorization.
- Confusing this object with user master maintenance: password resets, lock/unlock, and user group assignment are governed by S_USER_GRP and related objects, not by S_USER_PRO, so widening S_USER_PRO does not fix those unrelated failures.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-auth-objects/s-user-proERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.