CertPas

SAP Terminology

SAP Transport Requests: Types, Routes, and Operational Checks

Understand what SAP transport requests contain, how Workbench and Customizing requests differ, and how to check their path through a development landscape.

Transport Request PathShow the main checkpoints between recording a change and validating it in a target system.Transport Request PathShow the main checkpoints between recording a change and validating it in a target system.Record changeSelect the request type andrecord related work.Release requestCheck contents and complete therelease steps.Follow routeConfirm the configured targetand queue.Import and validateReview the import result andtest in the target system.CertPas original visual explanation
Process flow from recording a change in a request, through release and route checks, to import and validation in a target system.
Updated 2026-10-019 readReference guide
On this page
  1. What a transport request contains
  2. Workbench and Customizing request types
  3. How routes and transport layers work
  4. A safe request workflow
  5. Troubleshooting missing or incorrect changes

An SAP transport request is a tracked package for moving development changes between systems in a system landscape. It groups related objects or configuration changes so teams can review, release, and transport them in a controlled sequence. Knowing the request type and route helps diagnose why a change is missing or behaves differently after import.

What a transport request contains

A request records changes made during development or configuration. It normally contains one or more tasks assigned to users; the request organizer keeps those changes together for later release and transport. A request is a change container, not a guarantee that the change has already been imported into another system.

In practice, identify the request number, owner, short description, status, and included objects before moving it. Check that the request contains the intended changes and that dependent changes are accounted for. SAP terminology sits alongside other cross-functional concepts; see the SAP module overview for context on how modules organize business functionality.

Workbench and Customizing RequestsCompare the typical scope of the two request categories to guide initial request selection.Workbench and Customizing RequestsCompare the typical scope of the two request categories to guide initial request selection.Repository or developmentobjectConfigurationsettingWorkbenchRepository anddevelopmentobjects, generallyshared acrossclients.CustomizingConfigurationsettings, oftenmaintained for aspecific client.Check the changeConsider the object or settingand the intended target scope.CertPas original visual explanation
Comparison showing Workbench requests for repository and development objects generally shared across clients, and Customizing requests for configuration settings often maintained for a specific client.

Workbench and Customizing request types

A Workbench request is used for repository and development objects that are generally shared across clients in a system. Examples include ABAP development objects and dictionary objects. A Customizing request is used for configuration settings, often maintained in a specific client. The settings and the target client determine how those changes are applied.

The distinction matters when checking an unexpected result: a repository object can be present across clients while client-dependent configuration may need to be maintained or imported for the intended client. For client concepts and their operational implications, see SAP client terminology.

Diagnosing a Missing Transported ChangeProvide an operational sequence for tracing a change that is missing or has not taken effect.Diagnosing a Missing Transported ChangeProvide an operational sequence for tracing a change that is missing or has not taken effect.Check request statusConfirm the intended tasks andrequest are released.Check target queueVerify route, target system, andTMS queue.Review import resultUse the import log to investigatea reported failure.Validate contextCheck target client, object, anddependent changes.CertPas original visual explanation
Troubleshooting sequence: verify request release, confirm the target route and queue, review the import result, then validate the target client, object, and dependencies.

How routes and transport layers work

A transport route defines how requests move through connected systems, commonly from development to quality assurance and then production. A transport layer associates development objects with a route so the system can determine the intended consolidation path. The configured landscape and route determine where a released request is available for import.

Transport management is typically monitored through the Transport Management System (TMS), including its import queues. For hands-on queue and route operations, see SAP Transport Management System (STMS). The IDoc overview covers a different kind of SAP object: an IDoc is a data-exchange document, not a transport request.

A safe request workflow

  1. Create or identify the request that fits the change type and the system's change-control process.
  2. Record related work in the request tasks and check the object list before release.
  3. Release completed tasks, then release the request when its contents are ready to move. Follow local sequencing and approval requirements.
  4. In TMS, check that the request reaches the expected import queue and review the import result in the target system.
  5. Validate the change in the target system and client, including relevant dependent objects or configuration.

A request can be released successfully and still require an import step in the next system. Treat release and import as separate checkpoints when coordinating a change.

Troubleshooting missing or incorrect changes

Start with the request status and its object list. Confirm that the intended changes were recorded and that the relevant tasks and request were released. If an object is missing, check whether it was saved under a different request or whether a dependent change is still outstanding.

If the request does not appear in the expected queue, check the configured route, target system, and the TMS import queue. If it appears but import fails, use the import log and system procedures to identify the reported error, then address the cause before retrying. Avoid importing an uncertain or incomplete request into a productive system.

If the change imports but has no visible effect, verify the target client, the application context, and any required follow-up configuration or activation. For Customizing, confirm the relevant client and setting; for Workbench content, confirm the expected repository object and dependent components. Keep the request number and import result with the change record so the next operator can trace what happened.

Back to all articles