Send delivery orders to Conterminal by email

Sending or forwarding a delivery order

1. Attach the document. Only attachments are read on this path. Nothing you type in the message body becomes delivery-order data, so pasting a container number into the email does not rescue a missing or unreadable attachment.
2. Send to the delivery-order address. Put it in To or Cc, or forward the original message to it. Conterminal works out the intended recipient from the delivery headers first and the visible To line only as a fallback, so an address that appears solely in a forwarding rule still resolves correctly.
3. Send from a recognized address. The From address on the message decides whether the document is processed automatically or held for a person. See what trusted senders unlock below.
4. Expect one item per attachment. Every supported attachment on the message becomes its own Document Review item. A message carrying three PDFs produces three items, not one.

Resending is not free. Each inbound message is recorded as its own receipt, so mailing the same PDF a second time creates a second Document Review item rather than updating the first one. Chase the original item instead of re-sending, and archive the extra if you have already created one.

Supported attachments

Intake pulls three attachment types off an inbound message and ignores everything else. Both the MIME type and the filename extension are checked, so a correctly named file still works when the sending client sets a vague content type.

PDF

application/pdf, or any filename ending in .pdf. Read directly.

Word

.docx and .doc, or the matching Word MIME types. Converted to PDF before anything reads it, and the converted PDF is the copy you see in review.

When a message reaches the address with no PDF, DOC, or DOCX attached, Conterminal replies to the sender automatically and stops there. The reply body reads:

That reply keeps the original subject with Re: prefixed, or uses Re: Missing supported delivery-order attachment when the message had no subject. It goes to whoever sent the message, recognized or not, so an outside party who mails your address by mistake will receive it. A Word file that cannot be converted is treated as a permanent failure for that attachment rather than retried forever.

What trusted senders unlock

Conterminal decides ownership from the message's From address. That address is recognized when it matches any one of three things.

1. A user account in your workspace whose email is that address.
2. Your organization's own contact email, or its global notifications email.
3. An active entry on the workspace's delivery-order intake allowlist.

Exactly one workspace has to match. Zero matches records sender_not_authorized. If the same address is recognized by more than one Conterminal workspace, the document is held with sender_maps_to_multiple_organizations instead of a guess about who owns it.

Adding a sender to the allowlist

You add senders from the document they sent, not from a settings screen. Open the held document and use Trust sender to allow future documents from that address, or Trust sender & apply to trust the address and act on the document in one step. In the express review table the same two controls read Trust sender for future documents and Trust sender & apply tracking. Trusting a sender clears the warning on the document in front of you as well as allowing the next one.

What recognition actually buys

Recognized sender

The document is assigned to your workspace and staged for review or automatic tracking without anyone clearing a warning first.

Unrecognized sender

The document is held. If it reached your workspace address it is still yours and still visible in your queue, with the reason attached, but a person has to accept it.

Recognition is also the gate on the automatic reply described next. An unrecognized sender never receives one.

Configuring the automatic reply

A carrier workspace can answer the sender automatically once a trusted delivery order has been read, so the dispatcher who sent it knows it landed. Open Settings → Instant received confirmation. The panel appears only in carrier workspaces, and only a tenant admin can change it — everyone else sees the current mode and both templates as read-only text. An attempt to save without the role returns “Only trucker tenant admins can change this setting.”

1. Set Automation Mode. Choose Disabled or Trusted single-container send. Disabled is the default for every workspace, so nothing goes out until someone turns this on.
2. Choose Email Framing. Received — review in progress tells the sender the document arrived and is being validated. Confirmed — corrections only if something changes tells the sender the order is confirmed and that they will hear from you again only if something changes. Switching framing rewrites the stock templates but leaves templates you have hand-edited alone.
3. Edit the templates. Subject Template accepts up to 200 characters and Body Template up to 4,000. Neither can be empty. The supported tokens are {containerNumber}, {tenantName}, {replySubject}, {originalSubject}, and {senderEmail}. Anything else in braces fails the save with “The template contains an unsupported token.”
4. Check Sample Preview, then save. The preview renders both templates against a sample container and sender. Reset to defaults restores the stock copy for the framing you selected; Save Automation commits the change.

When the reply is suppressed

The send is deliberately conservative. Nothing goes out when the sender is not recognized for your workspace, when the workspace is not a carrier workspace, when the mode is disabled, when no container number was read at all, when a container reading is marked ambiguous or illegible, when the document carried field evidence but never marked a container as present, or when the reply recipients could not be established with confidence from the original thread. At most one such reply is ever sent per attachment.

Where the document appears next

Before anything is treated as a delivery order, the attachment is checked against two other paths. A proof-of-delivery document is recognized and routed to the proof-of-delivery flow, and an attachment that links straight to networked tracking is handled there. Only what is left is read for delivery-order fields. An interchange receipt is recognized later, from the document title and subject, and leaves the delivery-order flow before assignment, tracking, or the automatic reply can run.

Everything that survives lands in Document Review. The status rail in a carrier workspace splits the queue into Delivery Orders, Proof of Delivery, Interchange Receipts, and Unknown. A forwarder workspace uses a different rail — All Pending, Missing Fields, and Warnings — so held documents surface under Warnings there.

Delivery Orders

A recognized sender and a clean read. The document is waiting for you to resolve its assignments and confirm it.

Interchange Receipts

The attachment was identified as an interchange receipt and left the delivery-order flow early.

Unknown

Held for a person: an unrecognized sender, an authentication problem, or an attachment that could not be read.

An interchange receipt attaches itself to a delivery order only when its container number matches exactly one open delivery order in your workspace. No container number, no open match, or more than one match all leave it in the interchange-receipt queue to be assigned by hand. For the review work itself, see Work the Document Review queue and Review and confirm a delivery order.

What Conterminal keeps

Stored from the message

The complete original message, each original attachment exactly as sent, the converted PDF for Word files, a preview image, and the routing and authentication metadata used to decide ownership. Held documents are stored separately from clean ones but are not discarded.

Not used as evidence

Authentication headers carried inside a forwarded message. They are retained as part of the archived original, but only the result computed by Conterminal's own mail edge decides whether a sender is recognized.

Only the attachment is read for delivery-order fields. The message body is not, which is why an attachment that scans badly cannot be rescued by describing it in the email. The subject line is used, but only as a hint when classifying what kind of document the attachment is. The LFD conversation address is the mirror image: it stores message text and ignores attachments.

Troubleshooting