Tracking is enabled per port, not per integration. Each port carries a single tracking-level setting with three values, ordered from lightest to most detailed:

The tracking level toggle lives on the port itself, alongside the Exceptions option. See Ports → Options available on every port for the port-side description.

Tracking is filtered by the Selected Application. With a Selected Application set, every count and every row on the Tracking screen is restricted to that Application. With no Selected Application, the screen spans every Application the user has access to. The behaviour matches every other artifact list in the platform.

The Tracking screen is laid out in three regions, top to bottom, status boxes, a filter strip, and a results grid.

1. Status boxes. Five boxes at the top, each showing a status name and a live count: Successful Running Suspended Exceptions Errors. Clicking a box loads the matching records into the grid below; the same box also exposes an action menu that applies to the entire count at once (see Actions).

2. Filter strip. A row of filters that narrow what the grid shows: Tracking ID, Start Date, End Date, and Message Type. Filters compose with the active status box and with the Selected Application.

3. Results grid. One row per integration run, sortable by start time, with the originating port, message type, and start timestamp visible. Expanding a row reveals the run's full step-by-step history, see Step-by-step drill-down.

Actions are identical whether triggered on a single row or on the whole status box. The box variant applies the action to every record currently in that status, scoped by the active filters.

Expanding a row in the results grid exposes the full step-by-step history of that run, one line per step, in execution order, across every port the run touched. The columns are:

Each step in the drill-down carries a numeric Step ID, and the badge tooltip shows the stage it marks. A full two-way round trip spans two ports joined by the bus: the request enters through a receive port, is published, a send port picks it up and calls the external endpoint, and the reply returns through the send port and back out to the caller. The Step ID sets execution order, so the map and pipeline stages list in the order they run (a receive leg runs its pipeline before its map; a send leg runs its map before its pipeline). Most runs use only a subset.

Every integration run is stamped with a single Tracking ID when it enters the platform. The same ID flows through every port the run touches, which is what lets the screen reassemble one logical run from steps recorded by different ports. Use the Tracking ID filter on the top strip to recall the complete history of one specific run, even months later.