Skip to main content
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, and conditional. 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).
When you type into a password or payment field, the studio detects it and records the step with an empty, flagged value — the actual secret is never stored in the playbook. Supply sensitive values at runtime through input variables instead.

​
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:
The residential proxy options require proxy credentials configured at the platform level by an admin. Without them, enabling the proxy has no effect.
Disable local network protection is available on self-hosted (on-premise) deployments only, where the browser may need to reach internal network resources. It cannot be enabled on the managed cloud platform.

​
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

Navigate to a login page, fill the username and password from input variables, wait for the dashboard, click Export, extract the summary table into a text output, and download the PDF into a file output. Downstream nodes email the PDF and store the extracted figures.
Drive a multi-page form using input variables for each field, conditionally tick a checkbox if it’s present, select a value from a dropdown, submit, and screenshot the confirmation page into a file output as proof of submission.
Pair the node with a schedule trigger: navigate to a pricing or status page, extract the current values into list outputs, and let downstream logic detect changes and send alerts.

​
Next Steps