Browser Playbook

The Browser Playbook node runs visual browser automations as part of a flow. You record a sequence of browser actions once — navigating, clicking, filling forms, extracting data, taking screenshots, downloading files — and the node replays them on every run, streaming real-time screenshots and step results back to the workflow runner. It’s the right tool when a task lives behind a website with no API: logging into a portal to pull a report, completing a multi-step form, or scraping a dashboard on a schedule.

​

How it works

A playbook is a named, ordered list of steps. Each step is a single browser action (navigate, click, fill, and so on). When the node runs, it launches a browser, replays the steps in order, and collects any data the steps produce as node outputs. Playbooks include sensible error-handling defaults: if a step times out it retries, and if an element can’t be found the node falls back to AI-assisted recovery — an LLM locates the intended element so minor UI changes don’t break the run.

​

Recording a playbook

You build playbooks visually in the live browser studio rather than writing steps by hand.

1. Open the node’s configuration and click Record.
2. A live, interactive browser opens. As you navigate and interact, each action is captured automatically as a step.
3. The studio records resilient, multi-strategy selectors for every element (test IDs, ARIA roles, visible text, and CSS fallbacks), so playbooks keep working when a page changes slightly.
4. Stop recording and the steps are saved onto the node.

Recorded step types include navigate, click, fill, select, extract, screenshot, download, upload, wait, loop, conditional, and (in Editor V2) run script. A loop step repeats its child steps either a fixed number of times or once per value of a list — bind a list output from an upstream node (or reference a list input variable) and read the current value inside the loop as {{loop_item}} (with {{loop_index}} as its 0-based position). In Editor V2, the list can also hold objects — for example a Run Code output, a Generate Text List of Objects output, or a table’s rows. Read each key of the current object with {{loop_item.key}}, which is how you use several paired values in one iteration: a loop over [{"selector": "#a", "value": "1"}, …] can fill {{loop_item.selector}} with {{loop_item.value}}. Object values are coerced to text, and in nested loops the inner {{loop_item}} shadows the outer one. Once a list of objects is bound as the loop’s list, an Item keys field appears on the loop step. Declare only the keys the inner steps use there and the steps inside the loop offer loop_item.key in the variable picker, inserting the {{loop_item.key}} token (an inline chip in text fields). The declaration is editor convenience only; typing {{loop_item.key}} by hand works without it.

​

Running a Playwright script (Editor V2)

A Run Playwright script step runs Python Playwright code you paste or upload (a .py file up to 1 MB) inside the playbook’s live browser session, so it sees the same page, cookies and storage as the recorded steps around it. The code runs unchanged with page, context, browser, inputs and outputs in scope; if it defines run(page, inputs), that function is called and a returned dict is merged into outputs. Declare the step’s inputs (Text, Number, Boolean or JSON values, from literals, {{variable}} templates or bound upstream variables) and its output variables. Each declared output becomes an output of the node, a list when the step runs inside a loop, and the script must set every one of them (outputs['title'] = page.title()). {{variable}} tokens inside the code are not substituted; pass values through inputs. When the script raises, the step fails with the exception, its traceback and a screenshot. The step needs a sandbox image that ships Playwright, so it is unavailable on SECURE builds.

​

Inputs and outputs

Inputs are declared in the Input Variables setting. Each variable becomes a connector on the node and can be referenced inside any step with {{variable_name}} syntax. Supported types are Text, List of Text, File, and List of Files — for example, inject a username into a fill step or a report.csv into an upload step. Outputs are derived automatically from the steps that produce data: Two optional outputs can be toggled on in the configuration: a status boolean (did the playbook succeed?) and a browser session ID (when you keep the browser alive for downstream reuse).

​

Configuration

Beyond the recorded playbook itself, the node exposes these options:

​

Local vs cloud browser

By default the playbook runs on a browser hosted on the platform’s own infrastructure. This is fast and incurs no extra cost, and works for the majority of sites — add a residential proxy if you hit IP-based blocking. Enable Use cloud browser for sites with strong bot protection. The managed cloud browser provides real residential IP addresses, at the cost of higher latency and per-run expense. When the cloud browser is on, it handles connectivity itself, so the proxy options are hidden.

​

Limits and gotchas

• Headless execution — the browser runs without a visible window during a flow run. You only see the browser live while recording; at run time you get streamed screenshots in the Playbook Execution panel.
• 10-minute cap — a single playbook run is limited to 600 seconds.
• Recording sessions are short-lived — a recording session expires after roughly 30 minutes of inactivity, and only a limited number can be open at once. Save your playbook before stepping away.

​

Example use cases

​

Next Steps

• Learn about Inputs & Outputs
• Browse the node Catalog
• Automate runs with Triggers