SU56 — Display User Authorization Buffer

SU56 displays the authorization buffer of the calling user - the in-memory table the kernel actually consults every time an authority-check statement runs, built from the authorization values contained in all roles assigned to that user. The one structural fact that explains most confusion around it: the buffer is populated at logon and refreshed only on explicit reset or re-logon, so it is a session snapshot, not a live query against the roles as currently maintained in PFCG. A role added, removed, or regenerated after logon does not appear in SU56 for that session until the buffer is refreshed. SU56 is read-only - it shows what is loaded, it does not let anyone correct, add, or remove an entry.

SU56 gets pulled out mid-incident, after a user reports a 'no authorization' error and SU53 has already shown which authorization object and value failed the check. SU56 answers the next question: is that object present in the buffer at all, and with what values, which separates three distinct root causes - the role was never assigned, the role is assigned but the buffer has not been refreshed since assignment, or the role is assigned and current but the value in it genuinely does not cover what the transaction needs. It sits inside the authorization troubleshooting workflow rather than in provisioning; role assignment and generation happen in PFCG and SU01, and SU56 only tells whether that work has actually landed in the session.

There is no table to query for the buffer content itself since it lives only in memory. To prove a staleness theory, run SE16 on AGR_USERS filtered on the user ID to get the assignment date and validity period for the relevant role, then check USR02 for that user's last logon timestamp; if the role assignment date is later than the last logon, the current buffer predates the assignment and SU56 will not show the new entry. Cross-check AGR_1251 filtered on the role and authorization object to confirm the value actually exists in the generated profile, not just in the role's maintained definition that has not yet been regenerated.

SU56 is unchanged on S/4HANA; the buffer mechanism it displays is a kernel-level construct independent of the application layer redesign, so the same overflow and staleness behaviour applies on both. There is no Fiori app that replaces it because it is a diagnostic tool rather than a business transaction; SU53 and the authorization trace in ST01 remain its companion tools on S/4 exactly as they were on ECC.

This is security and authorization team territory, not functional and not routine Basis work, unless the root cause turns out to be a Basis-controlled buffer size parameter, in which case Basis owns the fix. A good handover includes the failing user ID, the exact transaction and timestamp, the SU53 screenshot from that moment, and the list of roles PFCG shows assigned to the user - without those three, the security team is repeating the reproduction step from scratch.

SU53 is the natural predecessor step, since it names the specific failing authorization object that SU56 is then used to locate inside the buffer. PFCG is where the actual fix gets made once the missing or incorrect value is identified. SU01 confirms role assignment and validity at the user master level. SUIM is worth learning next for querying authorization data across many users at once rather than one session at a time, and ST01 for tracing authority-checks live when SU53's last-failure snapshot is not enough to explain the pattern.