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.- Open the node’s configuration and click Record.
- A live, interactive browser opens. As you navigate and interact, each action is captured automatically as a step.
- 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.
- Stop recording and the steps are saved onto the node.
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:
| Step | Produces |
|---|---|
| Extract | Text |
| Screenshot / Download | File |
| Loop over extract/screenshot | List of Text / List of Files |
Configuration
Beyond the recorded playbook itself, the node exposes these options:| Option | What it does | Default |
|---|---|---|
| Input Variables | Declares the typed values passed into the playbook and referenced as {{variable}} | empty |
| Browser session ID | Reuse one browser across multiple Playbook nodes — cookies, tabs, and auth state are preserved. Scoped to a single workflow run; accepts input variables | auto-generated |
| Use cloud browser | Run on a managed cloud browser with real residential IP addresses, for sites with strong bot protection. Overrides the proxy setting | off |
| Use residential proxy | Route traffic through a residential proxy to bypass cloud IP blocks | off |
| Proxy region | Geographic exit region for the proxy — Automatic, North America, Europe, Asia Pacific, South America, Africa, or Middle East | Automatic |
| Custom window size / Window size | Override the browser viewport dimensions | off / 1280×720 |
| Output status | Add a status output (true/false) reflecting whether the run succeeded | off |
| Keep browser alive | Leave the browser open after the node finishes so a later node can reuse the session; emits the session ID | off |
| Continue if a file is missing | If a screenshot or download step produces no file, skip that output and continue instead of failing the run | off |
| AI model (advanced) | The model used for AI-assisted recovery when an element can’t be located | cost-optimized preset |
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
Pull a report from a portal
Pull a report from a portal
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.
Complete a multi-step form
Complete a multi-step form
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.
Monitor a dashboard on a schedule
Monitor a dashboard on a schedule
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
- Learn about Inputs & Outputs
- Browse the node Catalog
- Automate runs with Triggers