# Configuring Nodes (/docs/editor/configuring-nodes) Using node settings, input/output previews, and upstream data. Click a node to open its settings. On wide screens the settings open as a three-pane dialog; on narrow screens the same panes are available as tabs. Settings layout [#settings-layout] | Pane | What it shows | | -------------- | -------------------------------------------------------------------------------------------------------------------------------- | | **Input** | Upstream data available to this node. Use it to find variables, inspect sample payloads, and run previous nodes for fresh input. | | **Parameters** | The node's editable configuration fields and the main execute button for this node/trigger. | | **Output** | The node's live preview (for supported nodes) and last-run output. | The **Input** pane supports these data views: | View | Use it for | | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Variables** | Default input view. Shows an n8n-style variable browser with friendly chips instead of raw JSON syntax. Click a row to insert it into the focused parameter field, or copy it when no field is focused. | | **JSON** | Exact JSON tree with expand/collapse, path copying, and syntax highlighting. | | **Schema** | Shape-focused view for scanning object structure without reading every value. | | **Table** | Tabular view for arrays of objects or primitive arrays. | The **Output** pane supports **JSON**, **Schema**, and **Table** for last-run output. For Code and Transform nodes, the Output pane also has **Live preview** and **Last run** tabs. Search is available from the view toolbar. Horizontal scrolling is scoped to the data area so section headers and notices stay fixed while you inspect long keys or values. Common fields [#common-fields] * **Label** - display name shown on the canvas * **Credential** - which stored credential to use (for integration nodes) * **Operation** - what action to perform (e.g., "getPrice", "swap", "sendMessage") Some fields appear based on your operation selection. For example, selecting "swap" on Jupiter shows input/output mint fields. Template expressions [#template-expressions] Reference data from upstream nodes in any template-aware field using the node's response name: ```text {responseName.field.path} ``` Each node has a default response name (e.g., `birdeyeResponse`, `jupiterResponse`, `aiResponse`). You can change it in node settings. Examples: * `{birdeyeResponse.data.value}` - price from a Birdeye node * `{aiResponse.data}` - AI text or parsed JSON output * `{webhook.triggeredAt}` - timestamp from webhook trigger * `{json jupiterResponse}` - full output as a JSON string Use the `json` prefix when inserting an object or array into a JSON body or prompt and you need valid JSON instead of JavaScript string coercion. Inserting variables [#inserting-variables] For template-aware fields, click a value in the **Input** pane or use the variable picker beside the field. Solaris AI Flow inserts the correct expression at the cursor when possible, or copies it to your clipboard. For Code node JavaScript fields, Input-pane clicks insert `$input` access such as: ```js $input.pumpfunResponse.data[0].symbol ``` For normal template fields, clicks insert template expressions such as: ```text {pumpfunResponse.data[0].symbol} ``` If a node has no friendly response name, variable hints may fall back to the raw node-id path. Setting a clear response name makes downstream expressions easier to read. Response name [#response-name] Each node has a `responseName` field, or an equivalent output/result name, that controls how downstream nodes reference it. Defaults: | Node type | Default response name | | --------------- | ------------------------------------------------------ | | Manual Trigger | `trigger` | | Webhook Trigger | `webhook` | | Cron Trigger | `cron` | | Birdeye | `birdeyeResponse` | | Jupiter | `jupiterResponse` | | AI (OpenRouter) | `aiResponse` | | Telegram | `telegramResponse` | | HTTP | `httpResponse` | | x402 | `x402Response` | | Balance | `balanceResponse` | | Transform | Set **Name this result** yourself, such as `topTokens` | | Merge | `mergeResponse` | | Code | `codeResponse` | For Transform nodes, always name the result when another node needs to reference it. The UI previews examples such as `{topTokens.data}` because unnamed Transform outputs are harder to reference reliably. Running previews and node tests [#running-previews-and-node-tests] * Use the **Parameters** pane execute button to run the selected node, trigger, or workflow action shown by the button label. * Use the **Input** pane button to execute previous nodes when a node needs fresh input from upstream. The editor shows the nodes that will run and warns before running side-effecting ancestors. * Code and Transform nodes publish a **Live** preview in the **Output** pane while you edit. The **Last** tab still shows the most recent persisted run output. Preview/upstream runs count as monthly runs. They are hidden from normal execution history but still included in lifetime usage totals. Save and validation [#save-and-validation] Most node settings block **Save** until required fields are filled. If a node was imported or cloned with unsupported settings, the Parameters pane may ask you to choose a valid option before saving so the workflow does not silently change behavior. If you edit parameters, execution buttons may be disabled until you save. This prevents testing stale persisted config while unsaved edits are visible on screen. Next steps [#next-steps] * [Saving](/docs/editor/saving) - how workflows are saved * [Running](/docs/editor/running) - executing from the editor * [Run a Single Node](/docs/editor/run-node) - execute one node and its dependencies