Operation Node

Every data node is a host

A data node is an operation host. Its behaviour is an ordered list of operations, and the engine runs them in list order: each operation takes a row set in and emits the row set the next one reads. The last operation’s output is the node’s output port.

A new node starts with three slots:

1. Merge formula - reads the node’s incoming wires and builds the row set the native operation consumes. See Wires and named tables.
2. The native operation - what the node type does: Load file, Save file, the schema mapping, the AI call, the template.
3. Finish formula - shaping and styling after the native operation (setProp, keepProps, setStyle).

The two formula slots start empty and turned off, so a new node runs only its native operation. They show greyed in position on the node’s Explore tab, named Merge and Finish, so you can see where a formula goes before you write one. Writing a body and turning the slot on makes it a real operation; turning on an empty one is a check error.

An Operation node is the host with no native operation: its list starts with the two formula slots, and you fill it with whatever the work needs.

What you can add

Operation	What it does
Formula	Recommended. Ordered statements over the row set: set and drop fields, filter, sort, group, append rows from another wire, style cells, raise exceptions. Keeps per-cell lineage and styles.
QUERY	JSONPath, JSONata, SQL, or Jinja over the current rows. Query does not carry lineage or styles.
Script	A JavaScript or Python function per row. Scripts do not guarantee lineage; styles follow the whole input row.
The host’s native operation	What the node type does: Load file, Save file, the schema mapping, the AI call, the template. One per host, and the Operation node has none.

Operations run in order. A Query reshapes the whole table at its position, and the operations after it run on the rows it produced. Disabled operations are skipped.

A workflow authored before the operation host may still carry a row-wise operation on a node. It runs as it is, and its badge reads Legacy with the operation’s kind. Open it to see its stored configuration and Convert with AI, which asks an agent to rewrite it as a formula.

When you configure an operation badge, field pickers list columns from the stage input schema and the columns operations earlier in the same list created. You can still type a path manually when it is not listed.

On the canvas

The node card shows the node’s own face with every other enabled operation listed under it, in the order they run. A disabled operation is not on the card. Double-click the face to open the node editor, which always lists every operation.

A node shows one input port however many wires land on it. Drag an output onto that port to add another wire. Each wire gets its own name, shown on the wire, and a formula reads that wire’s table by the name.

Long lists cap how many badges the card shows. On Settings, Max Operations to Display (default 10) keeps the first N operations on the card. A family-color overflow marker sits under them in the same stack: +N more when some badges remain, or a centered N operations label when you set the cap to 0 (no individual badges). The overflow marker is not a button. Operations with exposed step output ports stay on the canvas when the cap is 1 or more so those siphon handles remain seated. When you set the cap to 0, siphon rows hide with the rest of the list. When the node uses siphon ports, the through-list exit path leaves the overflow marker, because the hidden operations are the rest of the list.

Turn on Compact operations without ports to draw each canvas operation that has no siphon as a 3px family-color bar with no label. Operations that expose step output ports keep the labeled compact badge and extend to the right edge of the node so the badge meets the output port.

Operations and data on the Explore tab

Every data node’s Explore tab carries the operations list beside the data, so you insert, reorder and edit operations where you read the rows. Expand or collapse the list with the panel control on the right of the node-editor tabs, and drag the split to change the column width. The Explore data shows the published output rows.

The editor’s data views are:

1. Split (default): linked input and output grids, including independent pairing when filter, sort, or group is in the list.
2. Grid: a maximised output grid with the same transformation presentation as the Split output pane.
3. Record: one output row as a form. Previous and next paginate output records. Each field lists the values it took through the list on one line (RT2 → mister → MISTER). Unchanged fields show the current value only. The field name stays on the left label. Changed fields use the same green text and changed dot as the output grid. Hover the written hop after the arrow to see the operation label that wrote it. Click that hop to scroll the operation into view in the list.

Hover an operation to highlight its source columns (amber) and output columns (indigo) in all three views. Hover a column header, or a Record field label, to highlight matching operations in the list. Hover a transformed output value to draw an indigo border on the operations that wrote it: Split and Grid highlight every writer in that field’s lineage, and Record highlights only the hop under the pointer. In Split and Grid, hovering an operation also borders every operation that writes the same output columns. In-place transforms use indigo. Highlighting does not persist and does not mark the workflow dirty.

Use Duplicate on an operation badge to copy that operation and its parameters into the same list, immediately after the original. Nested IF and SWITCH branches copy with new ids so you can edit the copy independently. Script copies get a (Copy) / (Copy N) label.

Quick Add includes Clone from existing… when the workflow already has at least one script operation. You pick any script on the current workflow (including nested IF and SWITCH branches and ones the composer wrote). The clone lands in the current node’s top-level list with a new id and a (Copy) / (Copy N) label so you can edit it independently.

Step output ports

On any host, you can toggle gets output port(s) on a top-level operation (plug control on the operation badge). That adds teal canvas output ports beside the matching operation so you can wire intermediate results, or IF/SWITCH branch row sets, to other nodes. The host output port (emerald) still carries every row after the full list.

When at least one step siphon is exposed, host output sits one pitch below the last operation row (below that row’s last siphon if it has one, otherwise the last badge). Canvas +N more (or the centered N operations label when the display cap is 0) is that last row when later operations are hidden. You do not need a siphon on every operation. The same pitch of clearance sits under host output to the node bottom. IF and SWITCH badges grow to cover every stacked siphon. Each siphon badge extends to the right node border so it meets its teal output port. A light through-list path shows how rows enter and leave to host output (not between operations). Collapsed IF and SWITCH rows show each siphon’s case next to its port (case Field='value', default, or true / false), right-aligned with the operation labels above, instead of the one-line switch summary. When you expose no step ports, the node keeps the classic layout: centered input and output, no exe path, no extra band under the list.

Hover a port on the graph to see its kind, label, id, and a row preview; click the port to pin the preview until you dismiss it. Output ports show that preview whether or not you wire them downstream. After a run, empty SWITCH and IF siphons show zero rows in the grid. Explore demo: Operation Step Output Ports (stamp and lane lists wire from host output; siphons stay on enrich intermediates and SWITCH branches).

After a run, hover a cell’s lineage marker on the node’s Explore tab to see where its value came from, hop by hop, with the value at each step. A green dot marks a value this node changed (hover it for the old and new value); a yellow dot marks a cell someone edited. Hover the thin gutter at the left of the row to see that row’s marks together.

Configuration

See Workflow schema for the full schema. A host’s operations live under custom.execution, which carries the list and nothing else:

{
  "custom": {
    "execution": {
      "operations": [
        {
          "id": "upper-side",
          "kind": "formula",
          "params": { "formula": "setProp(\"side\", prop(\"side\").upper())" }
        }
      ]
    }
  }
}

Each operation is { id, kind, params }, with optional enabled, exposeOutputPorts and (for a script) label. kind is the operation’s registry key: formula, query and script for the three generic kinds, <family>:<action> for a legacy row-wise operation a pre-decommission workflow still carries. A native kind (loadFile, saveFile, schema, ai, jinja, and one per other node type) carries that node’s own settings in its params.

A body can also live in another file: write { "$ref": "formulas.json#/clean" } in place of a value, or point a formula at an .ffl file and a script at a .js or .py file. New formula, query, and script bodies on a Workspace workflow land in a sibling <stem>-scripts/ folder. See JSON References.

On error

Each operation can set On error: raise error (run audit error) or raise exception (persisted workflow exception). See Exception management.

Related

• Formula - the recommended operation
• QUERY - dataset-wide Query operation (input_rows)
• Script - JavaScript or Python per row
• GROUP - collapse rows and aggregate
• SORT - reorder rows by one or more columns
• SWITCH - literal case branches on a discriminant field
• Lookup - the legacy enrich operation; a formula enriches with find on a named table
• Wires and named tables - how several wires reach one node
• Exception management - persisted exceptions and board