Why one message can visit several nodes
A visitor’s answer may lead through Extraction, Logic, and a Tool before the next Conversation response. This is expected when the steps are connected. A branch that loops through processing nodes without a conversational pause can exhaust the turn’s transition budget. Keep each turn’s path short and provide a recovery destination. When diagnosing a pause, look for an unwired branch or an action that has not returned before changing the model.Streaming responses
The editor receives a stream of structured updates from the flow runtime. It handles text, filler, discarded partial text, tool details, completion state, and errors. Discarded partial text means the runtime changed which response should be shown; it is not a second message to deliver to the visitor. If building your own client, use the current integration contract and handle completion and errors as well as text. Do not derive an API contract from the labels displayed by the editor.Bounded work per turn
The runtime limits node transitions and repeated tool rounds and trims retained history. HTTP requests also have a timeout. These bounds prevent a single turn from running indefinitely; they are not a target for flow design or a promise that an external write was canceled. For long-running work, design an explicit acknowledgement and a completion path supported by the integration. Keep the next conversational step independent of any result that is still pending.Draft versus published behavior
The editor test runs the draft. An assigned assistant uses a published flow. Saving a change is not sufficient to update that assistant: publish the flow, then verify the actual assistant channel.Diagnose a failure
- Conversation stops at a condition: inspect branch connections and the default destination.
- Repeated transitions: simplify the loop and add a question or clear exit.
- Action times out: check the external system before retrying a write.
- Earlier details disappear: store required information in explicit variables or your CRM rather than relying only on retained conversation history.
Runtime limits
These are execution bounds, not configurable editor settings or delivery guarantees.End Convo settings
The webhook body contains
event (conversation.ended), flow_id, session_key, end_node_id, end_node_label, variables, history, and summary. Summary contains total_messages, total_turns, nodes_visited, and ended_at. Counts reflect retained history; ended_at is an ISO timestamp. The webhook is sent without waiting for delivery, so inspect the receiver and make its processing safe to retry.
An end node is separate from the call lifecycle webhooks. Ending a flow does not itself establish delivery of either webhook.