Transports and imports

Every SAP transport request (TR) created in development becomes a Change in TENSOR, and that Change follows the transport through your landscape. Approvals, the change state machine and the post-implementation review gate apply unchanged. On top of the normal Change, TENSOR adds three SAP-specific cards: drift, collisions and the import schedule.

For the reasoning behind recording drift instead of blocking SAP, see SAP transport auto-sync — and why drift is recorded, not blocked. For the general Change process, see Changes and approvals.

Transports as Changes

• Auto-create. A transport first seen in a development system of a configured landscape becomes a Normal Change, titled from the transport description, exactly once. The Change is attributed to the mapped TENSOR user of the transport owner, otherwise to an explicitly audited system actor. The switch is on by default.
• Position sync. Release and import facts update the Change: released, imported to QA, imported to PROD.
• Close on PROD import. An import into production closes the Change through the change state machine and writes a sealing audit row. The post-implementation review gate still applies.
• Drift, not blocking. If SAP moved a transport further than the Change allowed, TENSOR records the fact instead of refusing it, raises a health event and shows a drift card on the Change.

Switching auto-create off stops new Changes only. Release and import facts of already linked transports are always recorded.

A new development transport does not create a Change when auto-create is off, when the system's SAP system CI is not marked as dev, when the SID has no CI, or when the transport header named no SAP connection.

Transport lifecycle

Drift kinds

Drift appears in three places: the Transport drift list on the Transports page of the SAP settings (/settings/sap/transports), the SAP transport drift card on the affected Change, and the connection's health events. When a PROD import could not close the Change, complete the Change manually.

The Transports page also lists Linked Transports: each TR with its type, SID, position and QA/PROD import marks. The page is not yet linked in navigation and is English only.

Object-level collision detection

TENSOR compares the object lists (E071) of all in-flight transports that have not yet reached production. If two transports change the same object:

• the Change page shows a Transport collisions card with the object and a link to the conflicting Change;
• the change calendar offers an SAP collisions view, listing each shared object with the transports involved.

A collision can only be overridden with the force-import right (change.sap_transport.force_import) and a written annotation. The override and the annotation are stored in the audit log. An import that proceeds despite a collision may overwrite, or be overwritten by, the other transport — review every conflicting Change first.

Import scheduling

The import itself is carried out by the Basis team in SAP STMS. TENSOR plans it, checks it against your maintenance windows and records its confirmation.

• Plan. Imports into DEV, QA and PROD are planned on the Change, in the SAP import schedule panel, with target system, planned time, sequence order and an optional maintenance window.
• Check the window. TENSOR checks that the maintenance window covers the target SAP system. If it does not — or the SID has no CI — scheduling needs a justification of at least 10 characters, which is audited.
• Execute in SAP. The Basis team runs the import in SAP STMS as usual.
• Confirm. The Basis administrator confirms the import in TENSOR, which timestamps it and checks separation of duties. The person who created the Change cannot confirm its import.

The import schedule panel is English only for now.

Release gating and automatic import from TENSOR — Planned, not yet available. Today TENSOR does not trigger imports or hold back releases in SAP; automatic import execution is a planned, consent-gated write-back extension.

Import schedule states

Separation of duties on transports

Transport SoD is partially available:

• Developer is not approver — enforced. The Change creator cannot approve the transport Change.
• Developer is not importer — enforced. The Change creator cannot confirm the import; a violation returns FORBIDDEN and is audited.
• Scheduling and confirming are split — sap.transport.schedule and sap.transport.confirm_import are never granted to one operational role.
• Approval stages are separate — not yet enforced. The rule is in the catalog, but enforcing it needs per-stage approver tracking.

Details are in Roles and permissions.

What each role sees on a transport Change

Step-by-step instructions are in Guides for change managers and the CAB.