Search Data node

The Search Data node embeds a query and finds the nearest stored vectors in the flow’s vector namespace, returning the top matches. Pair it with an Embed Data node that populated the same namespace.

Handles

Handle	Purpose
`Query`	The search question (a Prompt, Start input or text payload)
`Embed data`	The Embed Data node — orders execution, carries no query text
`Results`	The `[{ id, score, text }]` matches

Wiring

Embed Data and Search Data are not connected by data — they share the flow’s vector index (the namespace is the flow id, or <flowId>:<name> when a node carries a Knowledge base name). The Embed data handle only forces Search Data to run AFTER the documents are embedded; its payload never becomes the query.

Only Prompt and Upload File nodes may float without an incoming edge; every other node (including Search Data and Output) needs a path from the Start node.

Embed and search in one run (document in, results out):

Start ──▶ Embed Data (Input)                    (document in; or an
                                                 Upload File → Documents)
Embed Data ──▶ Search Data (Embed data handle)  (ordering only)
Prompt ──▶ Search Data (Query handle)           (the actual question)
Search Data ──▶ Output

The question arrives on the Query handle (or set the Query field and the handle stays empty).
The Embed data handle guarantees Embed finishes first — but its { embedded: N } output is ignored, so it can never become the search query.

Embed once, query per run (the vectors persist across runs):

Run 1: Start ──▶ Embed Data (Input) ──▶ Output        (store the documents)
Run 2: Start ──▶ Search Data (Query) ──▶ Output       (Query field empty → the
                                                       Start input is the query)

Use the same embedding model on both nodes, or the index returns nothing.

Multiple Embed Data nodes

Every Embed Data node in a flow writes into the same index (the namespace is the flow id), so they accumulate rather than overwrite — but re-running the SAME node replaces its own chunks, so re-embedding never creates duplicates. Search Data therefore searches across all of the flow’s embedded documents automatically — wire each Embed Data node into the Embed data handle to make Search wait for all of them, then search once:

Start ──▶ Embed Data A (Input) ──▶ Search Data (Embed data)
Start ──▶ Embed Data B (Input) ──▶ Search Data (Embed data)
Prompt ──▶ Search Data (Query) ──▶ Output

Separate knowledge bases

Give the nodes a Knowledge base name to split one flow into independent indexes: Embed Data writes into <flowId>:<name> and Search Data (or Chat) reads from the one carrying the same name. That is how one flow keeps, say, a handbook and a price list apart — without a graph edge between them.

All embedding nodes (and Search Data) must use the same embedding model.

Configuration

Model — the embedding model for the query. Must match the model the data was embedded with.
Query — the search query (may reference {…} templates); empty means the incoming payload.
Top K — how many matches to return.
Rerank model — optional. When set (default bge-m3), the node fetches a larger candidate pool and re-scores it for better relevance than raw vector distance.

Query examples

The Query field supports {…} templates and falls back to the incoming payload when left empty. Here are the common ways to search:

A fixed query — search the same thing on every run:

Query: "pricing plans and cancellation policy"

A template query — search for whatever the incoming payload carries, so the query adapts to each run. Reference any dot-path in the run context:

Query: "{payload.question}"
Query: "{input.customer_request}"
Query: "{outputs.agent_abc123}"

A query with surrounding text — mix fixed wording with a template value:

Query: "What does the handbook say about {payload.topic}?"

No query at all — leave Query empty and wire the incoming payload into the node. A string payload is searched verbatim; a non-string payload is serialized to JSON and searched as-is:

Query: (empty)  ← searches the text arriving on the input handle

Choosing the phrasing

Search is semantic, not keyword-based — the query is embedded and matched by meaning. Phrase it as the question or statement you want answered rather than isolated keywords:

Good:  "how do we handle refunds?"
Weak:  "refund policy money back terms"

Use Top K to control how many matches come back (fewer for a single focused answer, more when feeding an Agent a wider context), and enable a rerank model when the raw vector matches are close in meaning and you need the most relevant one first.

Output

The node returns a plain JSON array downstream nodes can read:

[{ "id": "…", "score": 0.87, "text": "…" }]

Each entry is the stored chunk with its vector id and similarity/rerank score.

Notes

Embedding + rerank costs are booked separately to your account credit.
An Agent with vector search enabled gets a vector_search tool over the same namespace, so it can retrieve embedded documents mid-answer (text output only — not with structured output).

Embed Data — populating the vector namespace.
Agent — vector search as a tool.