All nodes/Input / Output/Boundaries
Entry
Workflow entry point. Two OUTPUTS (does not pass through the raw envelope): output — for chat/telegram it is the message STRING, and with custom inputs (manual/API/editor run with an object without a message key) it is the ENTIRE input object → inputs.input.<field> directly; data — trigger context (trigger, chat.session_id, telegram.*; the webhook's structured payload is in data.webhook.payload). Get chat history via chat_history nodes. There must be exactly one. Has no exec_in.
Type in the graph: entry
Ports can be split into separate execution and data handles.
Try it
Message and trigger context
A template builds one string out of both entry outputs — the message text and the channel data.
- Execute + Data
Runs as pasted
When to use it
You do not choose the entry node — every workflow has one, and exactly one. What you do choose
is which of its two outputs to use: output is what the workflow was started with, data is
the circumstances it was started in.
How it works
output carries the message. For chat, the widget, Telegram and a webhook with text it is
a plain string: it has no fields, so {{ inputs.input.topic }} on it yields nothing. Turning
it into fields is a separate node’s job — structured_output_llm,
for instance. Files attached to the message travel with it and stay available downstream.
There are exactly two cases where output holds an object: a manual run, an API call or an
editor run with arbitrary JSON that has no message key — then the fields are read directly,
{{ inputs.input.city }}; and when an upstream node returned an object. If your workflow needs
structured data, hand it over that way instead of digging it out of a chat string.
data holds the trigger context, in a fixed shape: trigger, workflow_id, execution_id,
workspace_id, user_id, chat.session_id, plus telegram, webhook and cron (whichever
channel started the run is filled in, the rest are empty). A webhook’s or form’s structured body
lands in webhook.payload. Read it through an edge from the data port, or by name:
{{ nodes.entry.data.trigger }}.
The node has no execution input: the scheduler starts it itself, and it is the single point every other branch starts from.
Common mistakes
- A second entry in the graph. That is a
graph.multiple_entryerror and it blocks deploy. A second entry does not bring a second request: it receives the identical input and starts an unsynchronised copy of the branch — the work is done twice and billed twice. Draw parallel branches from the oneoutputand rejoin them with wait_all. - Reading
inputs.inputas “the workflow input”. It is whatever the node’s immediate predecessor delivered. A node placed after a template sees the template’s result there, not the user’s message. Address the entry by name instead:{{ nodes.entry.output }}. - Looking for the conversation history on the entry. It is not there — earlier turns are read by the chat_history node.
Inputs
—
Outputs
| Port | Wire | Payload | Notes |
|---|---|---|---|
Messageoutput | Execute + Dataexecute_data | message | |
Datadata | Datadata | — |
Configuration
This node has no configurable fields.
Shared fields
Every node has these three — the platform adds them, not the node author.
split_ports_in— Show separate execution and data input handles instead of one combined port.split_ports_out— Show separate execution and data output handles instead of one combined port.