Audience: EDI developers, B2B integration teams, system administrators

This article covers non-obvious behaviors and configuration tips for Advanced Delivery Settings and Transaction Forwarding. For setup steps, see the Advanced Delivery Settings and Transaction Forwarding product documentation.

Use GS IDs to route to different downstream systems when ISA IDs do not identify the final recipient

ISA IDs identify the interchange partners at the highest level, but they do not always represent the actual end customer or business unit a transaction is intended for. When a single ISA ID covers multiple logical recipients — each requiring different delivery — the GS segment's application sender code (applicationSendersCode, GS02) and application receiver code (applicationReceiversCode, GS03) carry the more granular identity of who the transaction is really for.

You can use either of these fields as a delivery condition path to route transactions to different communication channels based on their intended recipient. Configure a separate channel for each downstream system or business unit and add a condition on applicationSendersCode or applicationReceiversCode matching the relevant value. Each channel will then only receive the transactions intended for it, even though all transactions arrive through the same relationship.

Suppress external delivery with conditions

If you want certain transactions to stay in Orderful without being sent to an external channel, configure delivery conditions that only match transactions you want to deliver.

Make sure to also configure the communication channel "Keep In Ordeful" for transactions that don't meet the conditions to ensure the absence of external delivery is deliberate and not a configuration oversight.

Before Rules vs. After Rules per channel matters more than it looks

Each channel can independently receive the transaction before or after transformation rules are applied. This is useful when one system needs the original data and another needs the transformed version — for example, your ERP receives the transformed transaction while your audit log receives the raw original. Configure each channel's Transaction Revision setting accordingly rather than running two separate relationships.

Delivery conditions use JSON paths, not X12 segment names

Conditions reference the transaction's JSON representation, not the raw X12 structure. If you're writing conditions against X12 data, use the JSON field names as they appear in Orderful's transaction view — not segment element IDs like N102 or TD503. When including a qualifier check, the qualifier path and value path must share the same parent segment in the JSON structure.

Resending targets specific delivery states — use this to avoid duplicate deliveries

When resending on a multi-channel relationship, choose the most specific resend option rather than All Deliveries. Using All Deliveries resends to every channel including those that already confirmed delivery, which may cause duplicates downstream. Use All Failed Deliveries or All Failed and Sent Deliveries to target only channels that need a retry.

ISA IDs and X12 envelope segments are replaced — not passed through

When a transaction is forwarded, Orderful strips the original ISA, GS, ST, and SE envelope segments and replaces them with new ones appropriate for the outbound relationship. ISA IDs in the forwarded transaction reflect the outbound relationship's sender and receiver, not the original inbound. If your downstream system or partner expects specific ISA IDs, confirm they are configured correctly on the target outbound relationship, not the source.

Rules are not applied to forwarded transactions — configure them separately on the target relationship

Forwarding always happens before rules are applied. The forwarded transaction carries the original data with no transformations from the source relationship. This is by design — when a transaction is forwarded to a different relationship with new ISA IDs, the target partner typically has different requirements than the source partner, so the source rules rarely apply as-is.

If you do need the same rules on the target relationship, copy them from the source relationship and paste them on the target. Each relationship maintains its own independent rule set.

Auto Send on the inbound relationship controls automatic forwarding

Forwarding happens automatically only when Auto Send is enabled on the source inbound relationship. Validation status, delivery status, and acknowledgment status on the inbound transaction do not block or delay automatic forwarding — it triggers as soon as the transaction is received. If you need forwarding to wait for validation or manual review, disable Auto Send and forward manually.

Use the audit trail to trace original and forwarded transactions

Each forwarded transaction includes a reference to the original, and the original references the forwarded transaction ID. When investigating a downstream issue, start from either end — if you have the forwarded transaction ID, the audit message on it will point you to the original inbound transaction, and vice versa.

Forwarding requires JSON on your relationships sides — receiver on the source, sender on the target — not the partners' sides

The JSON format requirement applies to your own side of both relationships — the inbound relationship where you receive the transaction and the outbound relationship you're forwarding to. Your trading partner's side is not constrained: the partner sending the original inbound transaction can send X12, and the partner receiving the forwarded outbound transaction can receive X12. Orderful handles the format conversion at the delivery layer.

If you receive transactions in JSON format but need to deliver them to your own systems in X12, you can use Advanced Delivery Settings to force an X12 conversion on your communication channel — independently of the relationship's data format.

For system migrations, use multiple deliveries with format conversion instead of forwarding

If you're migrating from a legacy integration to a new one and need both systems to receive the same transactions during cutover, Advanced Delivery Settings is a better fit than Transaction Forwarding. Configure two communication channels on the inbound relationship — one for your new system and one for the legacy system — and use per-channel format conversion if the two systems expect different formats. This keeps everything within a single relationship and avoids the added complexity of a second outbound relationship and a separate trading partner setup that forwarding requires.