The Builder (Studio)

Studio is where workflows are made: a canvas-first editor embedded in the Nucleus, with the node library on the left, your graph in the middle, and a properties panel that slides in from the right when you select a step. Everything in this guide was captured from a live Flowdrome — what you see here is what you get.

The Studio editor with a three-node Telegram workflow on the canvas
The whole editor: library (left), canvas with a three-node Telegram echo flow, the Build / Runs / Settings switcher (top center), and Save / Test workflow / Debug / Import / Export (top right). The bottom bar is the unlimited undo history.

A quick map, clockwise from the top left:

  • Workflow name + status chipdraft until you deploy it; the line under it counts saved changes.
  • Build / Runs / Settings — Build is the canvas; Runs is this workflow’s run history; Settings holds per-workflow options (like test-run retention).
  • Save (Ctrl/Cmd+S), Test workflow, Playground, Debug, Runs, Console, Import, Export — the action row. The editor autosaves continuously, but only Save mints a version — see version history for labels, pins, diff and rollback.
  • The canvas — pan with the mouse, zoom with the wheel, fit with the zoom bar’s frame button. A dotted grid (configurable org-wide under Admin → Editor) helps line things up.
  • Auto-layout (top-left of the canvas) — untangles the graph with one click. More below.
  • History (bottom bar) — every change is an undo step; unlimited undo, with Undo/Redo buttons and a Compact action.

The node library

The left column is the catalog — every node, grouped into colored categories (Input, Processing, Logic, Error Handling, AI, Storage, Output, Utility, Workflow). Folders expand on click; the count chip shows how many nodes each holds.

The node library with the Input and Processing folders expanded
The library tree. Each entry shows the node's icon, friendly name, and a one-line description. The colors are the org's editor categories — configurable under Admin → Editor.

Typing in the search box filters live across names, descriptions and types, and force-expands every folder so matches are never hidden:

Searching the node library for 'http'
Search hits everything — here “http” surfaces the HTTP trigger, HTTP Request, and HTTP Response nodes at once.

Adding and wiring nodes

Drag a node from the library onto the canvas (or just click it to drop it near the center). To wire two steps, drag from a node’s output port (right edge) to another node’s input pin (left edge). Ports are typed and labelled — IF has True/False, Try has SUCCESS/ERROR/FINALLY — and the editor refuses connections that don’t make sense.

Dropping an HTTP Request node from the library, then wiring the trigger's output to its input — recorded live.
Auto-layout snapping a deliberately scrambled five-node graph into clean layers — it also saves the new positions.

The properties panel

Click any node and its panel opens on the right: an editable name, the Configure / Test / Data tabs, and a delete button. Configure renders the node’s properties — every node uses the same generic, typed property editor, with rich editors where they earn it (a cron builder for schedules, CodeMirror for JavaScript, the visual JSON editor for JSON fields, a structured rules editor for Switch).

The Telegram Trigger properties panel showing the credential picker
The Telegram trigger's panel. Note the credential picker — the bot token field is provided by the “telegram-bot” credential, so the secret never sits in the workflow. “+ New” creates a credential without leaving the editor.

Four field behaviours worth knowing:

  • {{ }} expressions. Any plain string field accepts a {{ }} expression — real JavaScript over the incoming item, evaluated per item at the node boundary: Order {{ $json.orderId }} — {{ $json.items.length }} items. Expressions even descend into JSON that arrives as a string (an HTTP body, say) — {{ $json.body.results[0].name }} just works.
  • Credential picker. Connection-shaped nodes carry a credential dropdown; picking one fills the secret fields with ${credential.name.field} references that resolve at run start. See Credentials.
  • Multi-selects and selects drive conditional visibility — properties appear and disappear based on other properties (the reference pages list every rule under “Shown when”).
  • The ⋮ button. Every text-entry field carries a ⋮ on its right that pops the value into the floating code editor — a full Monaco window (the VS Code editor) with a real language service behind it: type-aware completions for JavaScript and C#, $json field completions typed from your live sample data, {{ }} expression snippets, and ${variable.…} / ${credential.…} reference inserts. A Format button runs Prettier for JS/JSON/HTML and a Roslyn formatter for C#; indentation is yours to pick (2/4/8 spaces or tabs), and a vim mode is one toggle away (:w saves). Edits stream back into the field live.

Every node also carries validation badges (bottom-right of the node): a warning and an error icon that light up when the node’s verify rules find problems — a trigger with nothing connected, an invalid cron, unparseable JSON, empty code. Hover for the messages. You find out before you run, not after.

The AI Copilot

The toolbar’s Copilot button opens a chat window bound to the workflow on your canvas: ask what it does, tell it to make a change (“add a console between start and finish”, “change the url to …”), or open a blank workflow and describe what to build — edits land on the canvas immediately, with a live status line showing each tool the agent uses. It runs on your own model (local Ollama or a hosted provider) through the platform’s own MCP tools. Full guide →

Test workflow — run it for real

Test workflow executes the graph through the real runtime engine — real nodes, real HTTP, real envelopes — and paints the result onto the canvas: executed path highlighted, each node badged with its outcome, and a result pill at the bottom with the step count and total time.

A completed test run with the canvas lit and the run data panel open
After a test run of the CSV Pipeline demo: the executed path is lit, the pill reads “Run complete · Step 7/7”, and the selected node's Data tab shows its input and output envelopes.
A full Test workflow: press the button, the run executes, the path lights up, and clicking a node opens its captured data.

There is no slow playback animation — the result lands at once, on the final state. The pill’s Prev / Next arrows let you step back and forth through the executed order manually, which is the fast way to follow data through a long flow.

For conversational workflows there’s a second way to test: Playground opens an in-editor chat window where each message you type runs the saved workflow through the real engine (exactly the shape the Web Chat trigger delivers). The reply comes back as a chat bubble — with per-turn tool and guardrail chips and a hop trace — and the canvas lights up with the executed path, so testing a chat agent is just talking to it.

Reading run data

Click any executed node and its Data tab shows two envelope viewers: Input envelope — before this step ran and Output envelope — after. Flowdrome always shows the whole envelope — v, timestamps, correlationId, trace, and body with the payload inside — so what you debug is exactly what travelled the wire.

A node's Data tab showing input and output envelopes after a run
The Data tab after a run: input and output envelopes side by side, rendered by the visual JSON editor. Right-click any field → Copy Flowdrome path to get the exact expression for it.

The tree view is the same visual JSON editor used everywhere in Flowdrome: type badges per value, expandable containers, a Code tab for raw text, and — crucially — right-click → Copy Flowdrome path, which puts the correct {{ }} expression for that field on your clipboard.

Huge payloads don’t hurt: a node that emitted 100,000 rows ships a small preview to the browser, and the viewer lazy-loads more rows as you ask for them.

The Console dock is the run’s narration: Console nodes print timestamped messages, Show Image renders pictures inline, and Play Audio embeds an auto-playing audio player — live during Test/Debug (the dock opens itself on the first entry), listed in the Runs tab, and saved with the run. See the Console for the model.

The purple Run data floating panel appears when the flow contains Visualize (utility.inspect) nodes — each one is a watchpoint whose captured envelope shows up there, tabbed per node:

The floating Run data panel showing a Visualize node's captured envelope
Visualize nodes capture the envelope mid-flow. The panel is draggable and resizable, and offers the same copy-path affordance.

Debug — pause on the wire

Debug runs the same engine in stepping mode: the run pauses at every node and on every link, showing the full envelope at that exact point — and you can edit the data on the wire before letting it continue. Step, Resume, or Stop from the panel; you can even edit the parked node’s configuration and step into it with the new config.

The live debugger paused at the first node with the envelope editor open
Paused at the first node. The envelope is editable — change a field, then Step, and the run continues with your data. Execute Workflow nodes offer “dive in”: step into the sub-workflow and surface back.

The Runs tab

Build / Runs / Settings — the Runs tab lists every test run and debug session of this workflow, newest first, with status, step counts and durations. Selecting a run shows its trace: every node with its status and timing, the slowest steps card (the bottleneck, flagged), and the same input/output envelope viewer per node — including a per-port selector for multi-input nodes like Merge.

The Runs tab with a run list, trace, and envelope viewer
Run history. The left rail lists runs (expired ones are dimmed, archived ones restored from the saved document carry a chip); the trace column lists steps; the right panel shows whichever envelope you select.

Three power features live here:

  • Retry from a node. A failed run’s detail offers Retry from step — it re-runs from the failed node, seeded with the inputs recorded in that run. Upstream steps are not re-executed: no webhook re-fired, no email re-sent.
  • Compare. Pick any two envelopes — across runs — and diff them field by field, full envelope or payload-only, with JSON-in-strings parsed so HTTP bodies diff at field level.
  • Stop. A long test run can be cancelled from the toolbar; it lands as a clean canceled run, not a failure.

Import / Export

Export downloads the workflow as a JSON file — the graph plus captured run metadata, in the same flowdrome.workflow.v1 format everything else uses. Import accepts such a file and restores both. What you export is exactly what deploys; there are no converters between editor and runtime formats.

Frames: Try, Loop, Thread Pool, and Snippets

Four things on the canvas are frames — labelled containers you drop nodes into:

  • Try — an error boundary. Members run normally; if one throws it is retried per the frame’s policy, and the failure leaves on the frame’s ERROR port instead of failing the run. (SUCCESS and FINALLY complete the set.)
  • Loop Over Items — members run per batch over a list, with batch size and concurrency settings, collected on the frame’s done port.
  • Thread Pool — queue-fed concurrency: consume from an input queue, run the body on an elastic worker pool, feed an output queue.
  • Snippet — a purely visual grouping frame (find it in the library’s Workflow folder) for labelling regions of a big graph. The engine ignores it.

Drag a node into a frame to make it a member — membership is containment, and it survives save/reload because it’s part of the document. The Try and Loop reference pages show captures of both frames in action.

Next