Communication
Purpose
Everything the system says to the outside world goes through one sending path — to customers, prospects, portal users and suppliers alike.
The reason is not tidiness. A second sending path inevitably means a second place where sender, language, brand and logging have to be governed — and eventually a message missing from the thread because it bypassed the record.
Scope
- One dispatch service for every channel. New channels dock on as a further channel
implementation instead of building their own path.
- Brand-aware sender. Which account a message leaves through follows the brand — with a global
default as the safety net.
- Multilingual templates falling back to a cross-brand edition; what is maintained is the
difference, not every combination.
- The recipient's language decides. People are written to in the language held on their contact
record.
- Every dispatch leaves an entry in the thread and a delivery record. Sending a document creates
a thread entry — not a ticket.
- Delivery state on the entry. The chip on the thread entry shows Sent (handed to the sending
route), Delivered or Bounced once the delivery service reports back, and Failed if the message never went out. The reason is in the tooltip — for example smtp:550 … (the mail server rejected it) or twilio:30003 (number unreachable). Feedback comes from three sources: emails whose dispatch still fails after all retries (if the mail server rejects them, that means Bounced), bounce emails in the mailbox, and Twilio's status callback for SMS and WhatsApp (Delivered, Bounced). Without feedback it stays Sent.
- Bounces in the mailbox. When a non-delivery email only arrives later in the polled support
mailbox (IMAP or Gmail) or — for one-to-one mails sent through your own mailbox — in the connected personal mailbox (IMAP, Gmail or Microsoft), the system matches it to the original message — via its ID in the attached original or delivery report — and sets the chip to Bounced; the reason in the tooltip starts with dsn: and names the mail server's status code (for example dsn:5.1.1 … User unknown). A success report sets Delivered, a delay warning ("still being retried") changes nothing. A bounce never creates a new ticket — not even when it cannot be matched to any message; if a person forwards a bounce, it becomes a ticket as usual. The same applies in the personal mailbox: a bounce from the mail server is not filed (no assignment suggestion, no document intake). Prerequisite: bounces go to the sender address — it has to be the polled mailbox. An automation can react to every feedback: trigger Delivery feedback received (OutboundDeliveryReported), fields outcome (delivered or bounced), detail, recipient, subjectType, subjectId, mailTypeKey — for example a task "invoice undeliverable" on the customer.
- Token mails without stored content. Messages carrying access or one-time links are not stored
in clear text.
Interplay
Content comes from the mail templates, the route out from the system mail accounts, the appearance from the brand. Dispatch is triggered by functional modules or by the automation engine.
Limits
- Two deliberate exceptions. Marketing bulk mail runs through its own service provider, and
internal mail to your own staff — invitations, notifications, operations reports — does not run through the partner sending path.
- Tickets use their support mailboxes, so that replies land in the right thread.
- Without a configured sending account nothing goes out. That is intentional: silent dispatch
over an unknown route would be worse than a missing message, because nobody notices it.