Under the application’s Message types, create the two types this flow routes on. A message type is a name plus a format, no schema required:

Promotions live on the message type, so add them while you are here. Both delivery filenames (Steps 5 and 6) and the alert subject (Step 7) bind these tokens, and adapter parameters are plain strings: they take promotions, never body paths.

A failed relay re-publishes the document payload intact, but promotions are type-qualified, so the exception type needs its own:

Four remote systems, four credentials. Under the application’s Authentications, the dialog asks for a Name, the Adapter it pairs with, and a Definition, the credential shape that adapter offers, with the Application preset; the Definition decides the config section that follows.

Create the Scheduler receive port RelayClock; its tick is what wakes the fetch port (Step 4).

Create a two-way SFTP Caller send port CarrierFetch with the download command against the carrier’s outbound directory. Subscription: {{Config.PortName}} == "RelayClock". (The dropdowns can also create types and maps inline; building the dependencies first keeps each dialog a selection.)

Set Authentication to CarrierSftp, from Step 2.

The fetched file rides back as the response and re-enters the bus through the port’s Response stages: set Message Type Fallback to DispatchDocument, from Step 1, body untouched. Nothing tracks processed filenames for you; keep duplicates out the manual way, move fetched files aside on the carrier server if they allow it, or keep a processed-list the fetch checks (the note above).

A sample dispatch document as the carrier publishes it:

<DispatchAdvice>
  <DocumentNo>CMR-55812</DocumentNo>
  <Carrier>NordFreight</Carrier>
  <Consignee>Beltrans Customs BV</Consignee>
  <Packages>14</Packages>
</DispatchAdvice>

Create an SFTP Caller send port BrokerDelivery subscribing on {{Message.MessageType}} == "DispatchDocument".

Set Authentication to BrokerSftp, from Step 2.

The Filename is rebuilt from the Step 1 DocumentNo Promotion, so the broker copy and the archive copy (Step 6) always match, and a replayed document overwrites nothing at the broker (Fail if exists surfaces the duplicate instead):

BrokerDelivery : dispatch_{{Promoted.DispatchDocument.DocumentNo}}.xml
Archive        : dispatch_{{Promoted.DispatchDocument.DocumentNo}}.xml

Create a second SFTP Caller send port Archive on the same subscription, {{Message.MessageType}} == "DispatchDocument", with the same payload-derived Filename template as Step 5.

Set Authentication to ArchiveSftp, from Step 2.

On all three send ports, CarrierFetch, BrokerDelivery and Archive, set Exception Message Type to RelayFailed, from Step 1; the promotion you defined on it carries the document number into the alert subject.

Create the OpsAlert O365 Mail port subscribing on {{Message.MessageType}} == "RelayFailed":

Everything you configure is live the moment you save it, there is nothing to deploy. Start the send ports first, BrokerDelivery, Archive, OpsAlert and CarrierFetch, then the receive port RelayClock.

Set Tracking to Enabled + Body on every port the flow touches, so you can walk each run step by step, with its message body, in tracking.

Drop a test document on the carrier server, and confirm it appears on the broker server and under the archive path.

Stop the broker server, drop another document: the archive copy still lands, the delivery suspends and alerts, and replay drains it later. That asymmetry, flight recorder intact while a leg is down, is the test that matters.