S_TRANSPRT — Transport Organizer Authorization Object

S_TRANSPRT governs what a user can do with transport requests and tasks inside the Transport Organizer: create a request, add a task, change an existing request, release it, or delete it. It does not govern whether the user is allowed to change the underlying object, such as a table entry, a program, or a customizing setting. That check is separate and usually passes fine, which is exactly why S_TRANSPRT failures are confusing: the user has clearly been allowed to make the change on screen, but saving it fails because the system cannot record that change into a transport request the user is authorized to write to. The check also runs invisibly. A user maintaining a customizing table in SPRO never opens the Transport Organizer transactions, but the save triggers a background call into transport handling, and that is where S_TRANSPRT is evaluated.

The most visible checks happen in SE01 (Transport Organizer, extended view), SE09 and SE10 (Workbench and Customizing Organizer) when a user creates a request, adds a task, releases a request, or deletes one. STMS import queue actions also touch related transport authorizations, though the import step itself leans more heavily on system-level transport authorizations than on S_TRANSPRT. The less visible but far more common trigger point is any transaction that generates a transport entry as a side effect of saving: SE11 and SE80 for dictionary and repository objects, SE38 for programs, SPRO and table maintenance generators for customizing, and PFCG when roles are transported. In all of these, the user never explicitly touches a Transport Organizer screen; the popup asking for a transport request, or the automatic assignment to an existing one, is what triggers the S_TRANSPRT check behind the scenes.

Start with SU53 immediately after the failure, run by the affected user in the same session, before doing anything else. Because the check fires during save, SU53 usually captures it correctly even though the user was not consciously working in a Transport Organizer transaction. If SU53 is empty or ambiguous, switch to the authorization trace (ST01 classic trace or the newer trace transaction depending on release) and reproduce the exact save that failed, then filter the trace for S_TRANSPRT. Note the ACTVT and TTYPE values the trace shows as required versus what the user's roles grant. Capture the transport request number if one was already created before the failure, since that tells the security team which request type was in play. Hand the security team: user id, the actual tcode where the save was attempted (not the Transport Organizer tcode, which the user likely never opened), the request number if any, and the ACTVT and TTYPE pulled from the trace. Do not ask for S_TRANSPRT with full values as a first request; it is rarely the right fix.

This sits on the security or basis side, since transport authorizations are usually bundled into developer or key-user roles managed centrally rather than by functional teams. A good ticket names the user, the tcode where the save failed, the target request type if known, and the specific activity from the trace, rather than just 'cannot save changes'.