SE01 — Transport Organizer for Workbench and Customizing Requests
SE01 is the original Transport Organizer transaction. It shows a combined worklist of transport requests and tasks covering both Workbench and Customizing categories in one screen, unlike SE09 and SE10 which filter the same underlying data by request type. Use it to release, inspect, reassign, or delete transport requests when the request category is unknown or mixed.
This page covers SE01, the transport organizer transaction that lists both workbench and customizing requests together. It explains why SE01, SE09 and SE10 confuse consultants despite reading the same data, how to actually work a request from this screen, and the diagnostic checks for stuck, locked or missing requests.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,037 words
Purpose
SE01 is the original Transport Organizer, showing one worklist that spans both Workbench requests (programs, dictionary objects, function modules) and Customizing requests (table entries maintained via SM30 or IMG activities). SE09 is a restricted view showing only Workbench requests, and SE10 is a restricted view showing only Customizing requests. All three read the same underlying request store and offer the same release, display, and maintenance functions; they differ only in the default category filter applied when the list is built. This is the single fact that resolves most confusion: a request released in SE10 is fully visible and releasable from SE01, and nothing is lost or duplicated by switching between the three transactions.
When it is used
SE01 is used when a consultant needs to see the full transport picture without pre-guessing whether an object sits in a workbench or a customizing request, which happens constantly since a functional change often triggers both a table entry and a supporting development object. It is reached for during release day to sweep all open requests regardless of type, during troubleshooting when a change is missing in a downstream system and the request category is unclear, and when reassigning ownership or splitting a request into tasks. STMS remains the tool for the actual import into target systems; SE01 only manages requests in the source development system before that import happens.
How to use it in practice
- Call SE01
- Enter a user ID to see that user's requests, or leave it blank and select 'all users' to see every open request
- Choose the display mode, typically 'Requests and tasks', and set the status filter if only modifiable or only released requests are wanted
- Execute to see the hierarchical list of requests with their tasks nested underneath
- Expand a request node to see the tasks assigned to individual users, and expand a task to see the objects it contains
- Select the request or task line and use the menu path Request, Release, or the truck icon to release it
- Double click an object entry to jump directly into its editor for verification before release
Key data objects
- E070 - transport request header, holding request number, request type, status (modifiable, released, or in transport), owner, and target system
- E071 - the objects and keys included in a request or task, one row per object entry
- E07T - the short description text entered when the request was created
- E070C - additional request attributes such as project assignment and category classification
How to prove it in the data
In SE16, open E070 and filter TRKORR by owner or by date range using the AS4DATE field, and check the STRKORR and TRSTATUS fields to see whether a request is still modifiable ('D') or already released ('R' or 'N'). Take the TRKORR values returned and look them up in E071 to confirm which objects were captured, and cross check E07T for the request description to match it against what the developer expected to have saved.
ECC vs S/4HANA
SE01, SE09 and SE10 behave the same way on S/4HANA on-premise as on ECC; there is no Fiori replacement for this level of request-and-task management, and the classic GUI transaction remains the primary tool. In the ABAP environment on SAP BTP, transport handling is managed through a different service model rather than SE01, so this transaction should not be assumed available there without checking the specific environment.
Common pitfalls and how to diagnose them
- Stuck in modifiable status: the request was never released, so its objects remain locked and any dependent request cannot include the same objects; check TRSTATUS in E070 before assuming the change is missing downstream.
- Wrong category filter: a consultant searches only in SE09 or only in SE10 and concludes the change does not exist, when it sits under the other category; re-run the search in SE01 with no category restriction before escalating.
- Object locked by another open request: attempting to add an object fails with a message naming the other request; use SE03 to check the object directory and find which request currently holds the lock.
- Empty or abandoned requests accumulating: requests created but never populated or released clutter the worklist and confuse audits; use the delete function on empty requests rather than leaving them open indefinitely.
- Release blocked by inconsistency: release fails with a syntax or activation error in one of the included objects; check the object in SE80 or run a syntax check before retrying release, rather than repeatedly clicking release.
- Task not visible to the expected user: a task was created under a request but assigned to a different user ID, so the developer cannot see or edit it in their own worklist; check the task owner field, not just the request owner.
- Target system mismatch: the request's target system was set incorrectly at creation, so a correctly released request never reaches the intended system; verify the target system field in the request header before release, since changing it after release is not straightforward.
Whose problem this is
This is ABAP developer territory for request content, release timing, and object assignment, with a handoff to Basis once release is confirmed, since Basis owns the import path through STMS. A clean handover states the request number, its current status, the target system, and confirmation that release completed without errors.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/se01ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.