User Has the Role But Transaction Still Fails

The user says the role was assigned last week, or has always been there, and the transaction still throws a authorization error, sometimes with no useful message beyond 'you are not authorized'. The helpdesk checks SU01, sees the role sitting under the user's assignment tab, and escalates because 'the role is clearly there'. Sometimes the complaint is inconsistent: the transaction worked yesterday, or works for one plant or company code and not another, or works in QA but not production. Occasionally the user reports that a colleague with 'the same role' can run the transaction fine, which usually means the roles are not actually identical, just similarly named. The report almost never mentions org levels, profile generation, or authorization objects, because from the user's side the only visible fact is: role present, access denied.

Start with SU53 immediately after the failed attempt, but treat it as a hint, not proof, since it only shows the last object checked, not the full check sequence. Run an authorization trace with ST01 or the newer authorization trace transaction while the user reproduces the error, this shows every object checked and whether each passed or failed. Open PFCG for the role in question and check the traffic light status on the authorization data tab, confirm it is green and that the last generation timestamp is recent. Check the org level fields in the role for blank or asterisk values that should carry a specific value. In SU01, expand the role assignment line for the user and check the validity dates. If a composite role is involved, drill into each single role inside it and confirm each one is generated. Compare the role in the system where the user is failing against the same role in the design system using SUIM's role comparison to catch a missed transport.

Capture an authorization trace for the exact user, exact transaction, exact time window of the failed attempt. The trace output lists every object checked with its field values and the pass or fail result; the first failed line is the object to fix. Cross-check that object and its field values against the role's authorization data in PFCG for the same role listed in SU01, and confirm the assignment's validity dates cover the attempt date.

If the profile is ungenerated, regenerate it in PFCG and have the user log off and on; this is a data action inside the target system, no transport needed unless the underlying role definition also changed and needs to move from a design system. If an org level is blank, populate it in the derived role's authorization data and regenerate, this is a config change that must be transported through the landscape if the role originates upstream. If an authorization object is missing because it was never proposed, add it manually to the role's authorization data or fix the SU24 proposal for the transaction and regenerate; both routes require a transport if the role is maintained upstream. If the assignment validity period is wrong, correct the dates directly in SU01, this is a data fix local to each client and does not transport. If a transport was simply never imported, get it moved through the landscape rather than remediating the target system by hand, otherwise the fix will be lost on the next import. If the cause is a field value mismatch, correct the value in the role and regenerate, again a config change needing transport if the role is centrally maintained.

The reflex fix is to remove and re-add the same role to the user, or to add a broader role, or grant temporary SAP_ALL to unblock the ticket. Re-adding the identical role does nothing if the profile was never generated or the org level was never filled, because the same broken role is reassigned. Broad emergency access hides the real gap and tends to stay in place long after the ticket closes, becoming an audit finding later. Neither action tells anyone which object actually failed, so the next user who needs the same transaction hits the identical wall.

Security or GRC access management owns role generation, org level maintenance, and assignment validity. The functional module owner confirms which value the transaction actually requires, since security cannot guess the correct plant or document type. The handover note should carry the trace output, the failed object and field, the role name and system, and whether the fix needs a transport or was a direct data correction.