"I don't have authorization for this." It's the most common ticket in SAP security, and the fix is usually five minutes — if you know where to look. The single most useful transaction for these tickets is SU53, and understanding what it shows (and what it doesn't) will save you hours of guessing.
SU53: the last failed check
Here's the workflow. A user tries to do something and gets the dreaded "No authorization" message. Tell them — immediately, before they do anything else — to run transaction SU53 in the same session. SU53 displays the last failed authorization check for that user: the authorization object, the field names, the values the system required, and the values the user actually had.
The timing matters. SU53 shows only the most recent failure, and it resets with every new check. If the user runs three more transactions before calling you, the evidence is gone. Train your helpdesk to ask for SU53 output as the first step, not the last.
Reading the output is straightforward once you've seen it a few times. You'll see something like: object F_BKPF_BUK, field BUKRS, required value 2000, user's values 1000. Translation: the user tried to post in company code 2000 but their role only allows 1000. The fix is a role change, not a system problem.
Key takeaway: SU53 is a snapshot of one failed check, taken at the moment of failure. Get the user to run it immediately — it's the fastest path from "access denied" to the actual missing value.
S_TCODE: the gatekeeper at the door
Before SAP checks any fancy authorization object, it checks one simple thing: is this user allowed to start this transaction at all? That's the job of S_TCODE, and it's evaluated at transaction start, before anything else runs.
This is why a huge number of SU53 outputs show S_TCODE as the failed object. The user was never even let through the door. It usually means the transaction simply isn't in their role menu — someone asked for "access to MIRO" but the role only contains FB60, or the Fiori catalog doesn't include the app.
The fix for a failed S_TCODE check is almost always in PFCG: add the transaction to the role menu, maintain the authorization data, regenerate, and run the user comparison. Don't try to fix it by hand-adding S_TCODE values somewhere — the menu-driven approach keeps everything consistent.
When SU53 isn't enough: the trace
Sometimes the failure doesn't reproduce cleanly, or the user needs a whole sequence of checks analyzed rather than one snapshot. That's when you reach for ST01, the system trace. Turn on the authorization check trace, have the user repeat the failing action, then turn the trace off and analyze. You get every check the system performed — passes and failures — with the exact values compared.
ST01 is heavier than SU53 and you shouldn't leave it running, but for the stubborn cases — background jobs failing at 2 AM, Fiori apps throwing vague errors — it's the definitive tool. There's also SU24, which maintains the default check indicators for transactions (whether a transaction checks a given object at all, and with what default values). If a transaction should check an object but doesn't, SU24 is where that behavior is controlled.
Common SU53 patterns and what they mean
After you've read a few dozen SU53 outputs, the same patterns keep appearing. Missing S_TCODE means the transaction isn't in any of the user's roles — a menu gap, fixed in PFCG. Right object, wrong org value (required company 2000, user has 1000) means the role is scoped too narrowly for what the user actually does — either extend the role or create a derived one for the new org unit.
Right object, right org, wrong activity — required 02, user has 03 — is the trickiest, because it's a judgment call. Does this user genuinely need change access, or were they only ever supposed to display? Don't just bump the value; check with the role owner. And if SU53 shows an object you've never seen before with a cryptic name, that's often a custom authorization object (starting with Z or Y) from in-house development — the fix usually involves the development team, not just the role.
The troubleshooting habit
A clean authorization ticket follows the same pattern every time: reproduce the error, capture SU53 immediately, read the failed object and the missing value, decide whether it's a missing transaction (S_TCODE → menu gap), a missing org value (role too narrow), or a genuinely new requirement (role needs extending). Fix it in PFCG, regenerate, compare users, and have the user retest.
What you should not do is the thing everyone is tempted to do: slap SAP_ALL on the user "just to see if it works." It always works, it proves nothing, and if you forget to remove it — which happens more often than anyone admits — you've just handed someone the keys to the kingdom. SU53 first, always.