SE09 — Workbench Organizer for Transport Requests
SE09 is the Workbench Organizer, used to display, create, release and reassign transport requests and their tasks. It shares its underlying data and logic with SE10; the two transactions differ only in their default selection screen (workbench objects versus customizing entries), not in what they actually manage.
This page covers SE09, the classic transaction for browsing and releasing transport requests and tasks in an ABAP system. It focuses on the practical release sequence, the tables the transaction writes to, and the recurring failure patterns around locked objects, stuck tasks and misdirected requests.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,072 words
Purpose
SE09 is the Workbench Organizer, the tool used to view, create, release, and reassign transport requests and the tasks nested underneath them. The structural fact that causes most confusion: SE09 and SE10 are the same transaction logic pointed at the same tables, differing only in the default selection variant loaded on entry (workbench-type requests for SE09, customizing-type for SE10). Either transaction can display either kind of request if the selection screen is adjusted. A request holds one or more tasks, each owned by a developer; objects are locked against the task, not the request, and the request only moves when every task under it has been released.
When it is used
Reached for whenever someone needs to check what is sitting in their own open requests, find out who owns a task that is blocking an object, release a request after testing, or reassign a task to another developer who is picking up unfinished work. It sits between actual development work in SE80/SE38/etc and the transport landing in the target system. For monitoring whether a released request actually reached and imported into QA or production, the right tool is the transport management system, not SE09 — SE09 only covers the source-side lifecycle up to release.
How to use it in practice
- Run SE09 and adjust the selection screen if the default (own requests only) does not show what is needed; widen to all users or a specific request number.
- Execute and expand the tree to see requests, their tasks, and the object list under each task.
- Release the task first — this is what actually locks in the developer's changes; the request itself cannot release until all its tasks are released.
- Release the request once every task shows released status; check the return code in the release log immediately after.
- If a task or request needs to move to another owner, use the reassignment option in the menu rather than manually editing anything.
- To create a request from scratch (rare — most are generated automatically when an object is first changed), use the create function and choose the request type.
Key data objects
- E070 - request and task header: transport number, type, owner, status, target system.
- E071 - object list attached to each request or task: object name, object type, program ID.
- E070C - additional attributes for customizing-type requests, including client and target information.
- E07T - short description text entered for the request.
How to prove it in the data
Pull E070 in SE16, filter TRKORR by owner (AS4USER) and status (TRSTATUS) to confirm whether a request is still modifiable ('D') or already released ('R'/'N' depending on type). Cross-check TARSYSTEM to see where it is actually headed. Join on TRKORR into E071 to see exactly which objects the request or task carries, and compare that against the object the user claims is locked — mismatches here usually explain why someone 'can't find' the request that is blocking them.
ECC vs S/4HANA
SE09 is unchanged in structure and behavior on S/4HANA; requests, tasks, and the release mechanism work identically. Administrative Fiori apps exist for monitoring transports across landscapes at a higher level, but individual developers and consultants still use SE09/SE10 directly for day-to-day request and task handling. Extended systems using cloud ABAP development have a different transport model, but that is a separate context from the classic on-premise or private-cloud ABAP stack this transaction covers.
Common pitfalls and how to diagnose them
- Task stuck in modifiable status — the request will never release because one task under it is still open. Expand the tree in SE09, find the unreleased task, identify its owner, and either get them to release it or reassign it. Do not release the request without releasing every task first; the system blocks it, but people still waste time trying.
- Wrong selection filter — the request 'is missing' because the default screen only shows the current user's requests. Widen the selection to all users or search by request number directly before assuming the request does not exist.
- Object locked in a different request — an attempt to change an object fails with a lock message pointing at another transport number. SE09 will show the task, but finding which object is locked and by whom is faster in SE03; use that to identify and, if genuinely abandoned, release or reassign the lock rather than creating a duplicate request for the same object.
- Release failing silently — the return code in the release log shows a non-zero value (syntax error, missing include, locked object) but the person clicks through without reading it and assumes the release worked. Always read the release log, not just the fact that the status changed.
- Confusing release with import — a released request in SE09 has only left the source system's edit lock; it has not necessarily reached the target client. That part is transport management's job, not SE09's, and treating a green release log as proof of arrival in QA is a common and avoidable mistake.
- Mixed content in one request — customizing and workbench entries end up in the same transport because both were open when a change was saved, producing an inconsistent transport layer and import order problems downstream. Check the object list before release, not after.
Whose problem this is
Primarily an ABAP developer's tool for their own requests and tasks; Basis owns the transport management side once a request is released. A functional consultant only touches SE09 when a customizing request they generated needs releasing or reassigning. A good handover states the request number, current status, target system, and whether any task under it is still open.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/se09ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.