Flows

Chaining requests visually on a canvas — one response feeds the next, with conditions, extraction, and scripts.

In this chapter

What a flow is
Creating and editing flows
The canvas
Node types
Running a flow
Exporting a run report
Flow variables
Loops and safety

What a flow is

A flow is a visual pipeline of nodes on a canvas, where one node’s output can feed the next. Use flows to model multi-step sequences — authenticate, then create a resource, then verify it — without writing a runner script. Open the Flows panel from the Activity Rail (⌘4).

Creating and editing flows

Click the + in the Flows panel (Create a new empty flow) to make a New Flow, which opens as a tab already seeded with a Start node. Both the flow’s name and its canvas autosave as you edit (no Save button). Hover a flow in the list for a trash button to delete it.

The canvas

The flow opens on a dotted-grid canvas. Add nodes with the Add node button (top-left) or by right-clicking the canvas — both list the six addable node types. You can also drag a saved request from the Collections tree straight onto the canvas to create a linked Request node.

Wiring. Drag from a node’s output port to another node’s input handle to connect them. The wiring order sets the execution order: when a node fans out to several targets, the first-wired edge’s whole downstream chain runs before the next (depth-first).

Editing. Selecting a node opens its config panel on the right. Delete / Backspace removes the selected node or edge — except the Start node, which can’t be deleted. Pan and zoom the canvas freely.

Node types

Node	What it does	Ports
Start	The single entry point; no config. Exactly one is required.	one output
Request	Sends an HTTP request — either Linked (a saved request) or Inline (method, URL, headers, body, auth defined on the node). A `Treat HTTP 4xx/5xx as failure` checkbox controls which port fires.	Success, Failure
Condition	Branches on a value. Configure a Source (`$.json.path`, `status`, `responseTime`, `header:Name`, or `{{var}}`), an Operator (`equals`, `notEquals`, `gt`, `lt`, `contains`, `exists`, `regex`), and a Value.	True, False
Extract	Pulls values from the previous response into flow variables. Each row maps a source (`$.token`, `status`, `header:Name`) to a variable name.	one output
Delay	Pauses for a number of milliseconds (interpolatable, e.g. `{{retryDelay}}`).	one output
Script	Runs JavaScript between steps, with `pm.flow.get/set`, `pm.flow.lastResponse`, `pm.flow.stop(reason)`, plus `pm.environment` / `pm.globals`.	Success, Error
Input	Pauses the run and shows a form; the submitted values become flow variables.	one output

The Input node

An Input node pauses the run and prompts you with a small modal form — useful for a value you can’t know until run time (an order ID, an OTP, a one-off token), or a value that depends on an earlier response.

Configure it in the node’s Input panel: give the form a Form title, then add fields with + Add field. Each field has a Label (shown in the form), a Variable (the flow variable its value is written to), an optional Default value (pre-fills the field, and is interpolated so it can reference existing variables), and a Secret (masked) toggle that renders the field as a password input.

When the run reaches the node, it pauses and shows the form (The run is paused until you continue.). Fill it in and click Continue to resume — each value is written to its flow variable and is available downstream as {{variable}}. Cancel (or Esc, or clicking the backdrop) aborts the run as cancelled. Press Enter to submit.

Note: The values are written only as flow variables for the current run — an Input node never changes your saved environments or globals. Fields left with a blank Variable are skipped.

Running a flow

When the flow has a Start node, a Run button appears in its header (Run the flow from its start node, following the wired path.). While it runs, a Stop button lets you abort; switching away from the tab also aborts.

The run visualizes live: each node’s border reflects its phase (running, success, failed, cancelled), traversed edges animate, and a re-visited node shows a ×N visit counter. Selecting a node that produced a response shows its body and headers in a pane below. A collapsible Run log at the bottom lists timestamped, color-coded (info / warn / error) lines and the final Run <status>.

Exporting a run report

When the run finishes, a run report export appears next to the status in the header — the same one the Collection runner offers, with the same three formats (JSON report, JUnit XML, HTML report), the same Include bodies (JSON only) tick, and the same Export Report button. The file is saved as <flow>-run.<ext>.

What differs is what an entry is:

One entry per Request node the run executed, tagged with that node and its type — including one that failed outright, which lands in the report as an error. No other node type produces an entry, so Start, Condition, Extract, Delay, Script, and Input nodes are simply absent.
A node a loop visited more than once contributes its last visit — exactly what the run view shows. The report doesn’t invent history the run never kept.
A flow run counts as one iteration, however many times a loop went round; a node’s visit number is recorded on its entry instead.
Flow variables are never written into a report. Extract nodes, Input nodes, and pm.flow.set routinely park a token or a session id there, and none of those carry your secret flag, so Beacon has no way to tell which ones would need masking.

Masking works exactly as it does for the runner: credential headers lose their values, and every variable you marked secret — in an environment, in your globals, or in any collection the run’s linked requests came from — comes out as ••••••.

Your API key is masked wherever it is carried, including under a header or query-parameter name you invented (X-Company-Token): each step is masked against the auth that step resolved, so a request overriding its collection with its own key is covered too.

One thing a flow report can’t mask. If a script on one of the run’s requests rewrites a collection variable mid-run, the new value is a blind spot — a flow never saves collection-variable writes, so neither the before nor the after picture Beacon masks against contains it. Environment and global rotations are covered.

Flow variables

Extract nodes, Input nodes, and pm.flow.set write flow variables, referenced downstream as {{variable}}. In interpolation, flow variables take the highest precedence, then environment → collection → global. The run works on deep copies of your environment and global variables, so it has no side effects unless a script explicitly calls pm.environment.set or pm.globals.set — whether that is a Script node or a script on one of the requests the flow sends. Only the keys it changed are merged back and persisted. Collection variables are the exception: a run can set one and later steps using that same collection see the new value, but the write is dropped when the run ends.

Note: A linked Request node sends the saved request through the same path the Collection runner uses, so its collection’s and its own pre-request and test scripts do run — subject to that collection’s script trust gate, exactly as in a collection run. A Script node is for logic that belongs between steps rather than to one request; note that it runs with no collection in scope, so pm.collectionVariables.set inside one writes to nothing.

Loops and safety

Cyclic wiring is allowed and safe: a node can be visited up to a maximum (100 by default). Exceeding it fails the run with Loop cap exceeded on "<node>" (N visits), so a runaway loop stops on its own. A Script node can end a run cleanly at any point with pm.flow.stop("reason").