Start free

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. It has no run input — the platform starts it.

Entry
Message
Trigger data

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.

Entry
Template▶
Exit▶
  • Execute + Data
Press “Copy nodes”, open the editor and hit Ctrl+V on the canvas.

Runs as pasted

When to use it

You do not choose the entry node — every scenario has one, and exactly one. What you do choose is which of its two outputs to use: output is what the scenario 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 scenario 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_entry error 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 one output and rejoin them with wait_all.
  • Reading inputs.input as “the scenario 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

PortWirePayloadNotes
MessageoutputExecute + Dataexecute_datamessage
Trigger datadataDatadata—

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.

Ready-made examples using this node