> ## Documentation Index
> Fetch the complete documentation index at: https://docs.noxus.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Browser Playbook
> Record and replay browser automations — navigate, fill forms, extract data, and capture screenshots inside a workflow
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**.
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:
| Step | Produces |
| :--------------------------- | :--------------------------- |
| Extract | Text |
| Screenshot / Download | File |
| Loop over extract/screenshot | List of Text / List of Files |
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:
| 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
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
* Learn about [Inputs & Outputs](/platform/flows/inputs-outputs)
* Browse the node [Catalog](/platform/flows/nodes)
* Automate runs with [Triggers](/platform/flows/triggers)