S_USER_TCD — Controls Which Transaction Codes Can Be Added to Roles
S_USER_TCD restricts which transaction codes a security administrator can insert into a role's menu or authorization data in PFCG. It does not control whether an end user can execute a transaction — that is S_TCODE. Confusing the two is the single most common cause of wasted troubleshooting time on this object.
This page covers S_USER_TCD, the authorization object that gates role administration rather than end-user execution. It explains the single field checked, where PFCG enforces it, and how to distinguish a role-build failure caused by this object from an ordinary end-user authorization shortfall.
Reviewed by an ERPClimb SAP consultant on 16 Sept 2026· 821 words
What it protects
S_USER_TCD is a role-administration control, not an execution control. It determines which transaction codes a person maintaining a role in PFCG is allowed to add to that role's menu or transaction list. It has nothing to do with whether the eventual holder of the role can run the transaction — that check belongs to S_TCODE, evaluated at execution time against the user's own authorizations. The structural fact that causes most confusion: a role can be fully built, saved, and transported with S_TCODE for a given code, yet the administrator who built it may have needed S_USER_TCD for that same code just to type it into the role in the first place. Two different people, two different objects, two different points in the timeline, and the symptoms look identical from the outside.
Fields checked
- TCD - the transaction code being added or maintained in a role's menu or transaction assignment. Values are specific tcodes or a wildcard for administrators with broad role-build authority. This is the only field carried by S_USER_TCD; there is no ACTVT field, so the check is a simple presence-of-value test against the list assigned to the person editing the role.
Where it is checked
- PFCG - when a transaction code is added to the Menu tab of a role and the role is saved. The check runs for the person editing the role, not for the eventual role holder.
- PFCG mass role maintenance and role copy - copying a role with an existing transaction list can still trigger the check if the target role save re-evaluates the transaction assignment.
- Decentralized or delegated role administration scenarios - business-unit role owners with restricted S_USER_TCD values are stopped from inserting codes outside their assigned scope, by design.
- Not checked at all during normal end-user execution of a transaction. A user with a role containing the tcode executes fine regardless of who could or could not add it during role build.
How to trace a failed check
Confirm first who actually hit the error: it is the person editing the role in PFCG, not the end user who will eventually hold it. If that distinction is unclear, the trace effort goes to the wrong person and wastes a cycle. Have the role administrator reproduce the failure and immediately run SU53 in their own session — it shows S_USER_TCD failed with field TCD carrying the specific transaction code they tried to insert. If SU53 is ambiguous or was run too late, start an authorization trace (ST01 or the newer trace transaction) for that administrator's user ID, reproduce the save, then stop the trace and filter for S_USER_TCD. Hand security the administrator's user ID, the exact tcode value attempted, the role being edited, and the timestamp. Do not hand them the end user's ID or a screenshot of the end user's own S_TCODE failure — that is a different problem entirely and will send the investigation in circles.
Whose problem this is
This is a security team problem, almost without exception. It surfaces only when someone is building or maintaining roles, which functional consultants do occasionally in decentralized administration models but rarely otherwise. A good request states the administrator's user ID, the role name being edited, the specific transaction code that could not be inserted, and a one-line business justification for why that administrator's scope should include it.
Common pitfalls
- Treating a failed S_USER_TCD check as an end-user authorization gap and escalating to the wrong team. The end user's role may be perfectly correct — it simply never received the tcode because the administrator building it was blocked at the insertion step.
- Granting S_TCODE broadly to a security administrator's own user and expecting that to fix a PFCG insertion failure. S_TCODE controls execution, not role editing; it does nothing for this check.
- Wildcard TCD in S_USER_TCD for senior security admins, and a short explicit list for delegated or business-unit role owners. When a business owner tries to add a code outside their list, the failure looks like a broken role rather than a deliberate segregation-of-duties boundary, and people push to widen the wildcard rather than route the request properly.
- Re-running PFCG repeatedly with the same result and concluding the role transport or the role itself is corrupted, when the actual blocker is the administrator's own authorization for that field value.
- Capturing SU53 from the wrong session — typically the end user's — which shows a clean or unrelated result and sends the investigation looking at the wrong object entirely.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-auth-objects/s-user-tcdERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.