SE10 — Customizing Organizer for Transport Requests

SE10 opens the Transport Organizer with an initial filter set to show Customizing requests belonging to the logged-in user. From this screen a consultant can view a request tree, drill into the tasks under a request, see which objects a task contains, release a task or request, or reassign ownership. The structural fact that explains most confusion: SE10 and SE09 are the same tool. They differ only in the default category selected on the initial screen, customizing versus workbench. Once inside, the display variant can be changed to show any request type, any user, any status. Treating SE10 as a customizing-only tool and SE09 as a workbench-only tool leads people to search the wrong screen when a request does not appear where expected.

SE10 gets used whenever a customizing change made through the IMG needs a home, and someone needs to check what request it landed in, add objects, or release it for transport into QA or production. It is also the first stop when a change refuses to transport, when an object appears locked to another user, or when a cutover checklist requires confirming every open request is released before a system freeze. Consultants reach for it instead of the IMG's own prompt screen when they need to see the full picture across multiple requests and tasks, not just the one popup tied to the current change. STMS is the tool for moving a released request between systems; SE10 is the tool for managing the request before that point.

In SE16 on E070, filter TRKORR by the developer's user id in AS4USER and by TRSTATUS to find modifiable requests (D) versus released ones (R). To find what is actually inside a request, join to E071 on TRKORR and filter OBJ_NAME or OBJECT to check whether the expected table or program entry is present. For customizing table changes, cross-check E071K to confirm which specific key was captured, since a request can exist and be released but still miss the actual row that was changed.

SE10 behaves the same way on S/4HANA as on ECC; the Transport Organizer and the underlying request tables are unchanged. There is no Fiori app that replaces request management itself, though individual customizing activities may now be exposed through Fiori-based configuration apps that still generate the same requests behind the scenes. Nothing about the release mechanics or the SE09/SE10 relationship changes on S/4HANA.

Managing an individual request is normally the responsibility of whoever made the change, functional or ABAP. Basis owns the transport landscape itself, the queues, and system-level release rules. A good handover names the request and task numbers, the target system, and flags any object shown as locked elsewhere so Basis is not asked to chase something that is a locking issue, not a landscape issue.

SE09 is the same tool with the workbench filter as the default, worth reading alongside SE10 to stop treating them as separate products. SE01 gives the broader transport organizer view across all request types and is useful when a search needs to span both customizing and workbench requests at once. SE03 covers the deeper transport tools, including where-used checks for locked objects. SM30 and SM31 are worth knowing because the actual customizing table entries that end up inside an E071K record are maintained there, one layer below what SE10 shows.