Web Flow Node

The Web Flow node allows you to automate interactions with web pages using CSS selectors, XPath, data-testid, and text. It is ideal when you need traditional selectors and detailed control over element location.

Tip: If you prefer semantic locators based on accessibility (getByRole, getByLabel, etc.), use the Smart Locators node.

Overview

General Configuration

Browser

Firefox and WebKit are downloaded automatically on first use if not already installed.

Device — Desktop

Available viewport presets:

Device — Mobile

Uses real Playwright device profiles (viewport, user agent, pixel scale ratio, touch). Available models:

iOS: iPhone SE, iPhone 12, iPhone 13, iPhone 14, iPhone 14 Pro, iPhone 15, iPhone 15 Pro, iPad Mini, iPad (gen 9), iPad Pro 11

Android: Pixel 5, Pixel 7, Galaxy S8, Galaxy S9+, Galaxy Tab S4

When using Firefox with Mobile mode, the isMobile and hasTouch options are automatically stripped (not supported by Firefox in Playwright). Viewport and user agent from the device profile are still applied.

Session Mode

• New Session (new): Opens a new browser for each execution. Ideal for isolated tests.
• Reuse Session (reuse): Uses a browser session already opened by another Web Flow/Smart Locators node. Useful for splitting long tests into multiple nodes while keeping the same browser and cookies.

Storage Strategy

• In Memory (inMemory): Cookies and localStorage are discarded at the end of the execution.
• Persisted (persisted): Cookies and localStorage are saved with a key and can be reused in future executions. Ideal for maintaining login sessions between executions.

Steps (Web Steps)

The Web Flow node executes a sequence of configurable steps. Each step represents an action in the browser.

Available Actions

Selector Strategies

Web Flow uses selector strategies to locate elements on the page. Each step can have multiple strategies ordered by priority — if the first one does not find the element, the next one is tried.

Recommended priority:

1. dataTestId — Most stable, does not change with layout
2. css with ID — Usually unique on the page
3. role — Accessibility-based
4. text — May change with translations
5. xpath — Last resort, most fragile

Action Details

navigate

Navigates to a specific URL.

Example:

URL: https://mysite.com/login
URL: {{ variables.BASE_URL }}/dashboard

click

Clicks on a page element.

The click tries to locate the element using each strategy in order. If it fails, it waits and tries again (up to the number of retries).

type

Types text into an input field.

Note: The type action uses Playwright's fill(), which replaces the field value instantly. To simulate character-by-character typing, use the Smart Locators node with the type action (pressSequentially).

wait

Waits for a condition before proceeding.

Modes:

assert

Verifies a condition on the page. If the condition fails, the step is marked as failed.

Modes:

Assertion results are available in the outputs:

{{ steps["web-flow"].outputs.asserts.assertionName }}  →  true or false

extract

Extracts data from a page element.

Attributes:

Extracted data is available in the outputs:

{{ steps["web-flow"].outputs.extracts.extractionName }}

hover

Hovers the mouse over an element.

scroll

Scrolls the page or to an element.

Modes:

refresh

Reloads the current page.

Events:

select

Selects an option from a <select> element (dropdown).

Criteria:

press-key

Presses a keyboard key.

frame

Switches context to an iframe.

Modes:

Evidence (Screenshots)

Each step can have individual evidence configuration:

Accessibility Testing

Web Flow supports automatic accessibility scanning with built-in axe-core. When enabled, the node audits the page after each step that captures a screenshot, identifying WCAG/ARIA violations and visually marking the affected elements.

Configuration

How It Works

After each step that takes a screenshot, axe-core is injected into the page and scans the document for violations. Violations are drawn over the screenshot as colored boxes around the affected elements, plus a summary panel in the corner:

At the end of execution, the following are generated automatically:

• Per-step screenshots — overlay with colored boxes + panel Critical N / Serious N / Moderate N / Minor N + top 2 rules
• Severity chart — {id}-accessibility-severity-chart.png — distribution by level
• Rules chart — {id}-accessibility-rule-chart.png — top 8 most violated rules
• JSON report — {id}-accessibility-report.json — full data for all violations

Pass/Fail Criteria

The node fails if there is any violation with severity equal to or above the configured threshold. Use none to never fail (collect metrics without blocking the flow).

Example: Login audit

Node configuration:
  Accessibility Scan: true
  Fail When Severity >= : serious

Steps:
1. navigate → https://mysite.com/login    (no screenshot = no scan)
2. type → #email → "{{ variables.EMAIL }}" → screenshot after → scan executed
3. click → button[type="submit"]           → screenshot after → scan executed
4. wait → networkIdle
5. assert → loginOk → hasURL → /dashboard → screenshot after → scan executed

If any step has a serious or critical violation, the node fails with:

"Accessibility findings at or above "serious" were detected."

Outputs

Complete Example

Logging into a website

Steps configured in the node:

1. navigate → https://mysite.com/login
2. type → Selector: #email, Text: {{ variables.USER_EMAIL }}
3. type → Selector: #password, Text: {{ variables.USER_PASSWORD }}
4. click → Selector: button[type="submit"]
5. wait → Mode: networkIdle
6. assert → Name: loginOk, Mode: textContains, Selector: .welcome, Text: Welcome
7. extract → Name: userName, Selector: .user-name, Attribute: text

Result: After execution, the outputs will be:

{
  "sessionId": "abc-123",
  "extracts": { "userName": "João Silva" },
  "asserts": { "loginOk": true }
}

Tips

• Use data-testid as the primary selector strategy — it is more stable
• Configure screenshots on critical steps to make debugging easier
• Use session reuse when multiple Web Flow/Smart Locators nodes need to share the same browser
• For forms with autocomplete or input masks, consider using the Smart Locators node with the type action (character-by-character typing)
• headless: false mode is useful during development to visualize what the test is doing