Channel persistence
Each Send node has a channel chain — an ordered allowlist of channels the engine may try (e.g. [whatsapp, telegram, email]). The engine walks the chain and picks the first channel the contact has a usable contact method for.
When a node has no chain of its own, it falls back to the flow-level default channel chain chosen in the creation wizard (see Overview → Default channel chain).
Prefer originating channel
In Flow settings → Prefer originating channel (default: on), the engine biases its choice toward the channel the contact entered the flow on.
- On — if the contact's originating channel is in the node's
channel_chain, use it. Otherwise fall through to chain order. - Off — strictly honour
channel_chainorder, ignoring the originating channel.
This matters when a contact starts a flow from a WhatsApp message but a Send node lists [email, whatsapp]. With prefer originating channel on, the message goes out on WhatsApp (matches the conversation). With it off, the message goes out on email (chain order wins).
Choosing the right setting
| Use case | Recommended setting |
|---|---|
| Conversational flow (bot, support) | On — keep the thread on one channel |
| Broadcast-style notification | Off — pick the cheapest / most reliable channel |
| Email-first transactional sequence | Off — put email first in channel_chain |
| Multi-channel reactivation | On — return to the channel they last engaged on |
The originating channel is captured when the run starts (manual trigger uses the inbox the operator picked; API trigger uses the channel_id you pass; reply trigger uses the message's channel).
Interaction with templates
For WhatsApp Send nodes that require a template (outside the 24-hour session window), the engine still respects the chain — if the only available channel needs a template and you haven't picked one, the node fails and the run continues per its error-handling configuration.
See Send node for the full node config schema.