UI Workflow Steps

Each step in a UI Workflow suite describes one action in plain language — "Click the Sign in button," "Type {{EMAIL}} into the Email field." This page covers the parts of a step beyond the action text: navigation, headers, and session isolation.

Continue vs. Go to URL

Every step has a Navigation setting, right next to the action text — mirrors the Method dropdown on API Workflow steps, so the two editors read the same way.

• Continue (the default) — the step acts on whatever page the previous step left open. No navigation happens.
• Go to URL — the step starts by navigating to a Starting URL you provide, then carries out its action from there.

A suite's first step is implicitly a "Go to URL" step in spirit even if you don't set one — but in practice you'll almost always want a Starting URL on at least the first step, since there's nothing to continue from yet.

A step's browser session carries all the way through a suite by default — a "Go to URL" step navigates to a new page in the same browser tab, it doesn't start a new one. That's what lets a step that logs in keep a later step signed in, and it's also why a step you'd expect to just "continue" (see Run separately below) can actually be either Continue or Go to URL and behave the same way session-wise — the only real difference is whether it navigates somewhere first.

Headers

When a step navigates to a URL, you can attach HTTP headers to that request — same key/value list as API Workflow steps, and header values support the same {{VARIABLE}} interpolation.

The most common use is authenticating past something in front of your target, like an Authorization: Basic <base64> header for a site behind HTTP Basic Auth. A couple of things worth knowing:

• Headers carry forward, the same way session does. A header set on one step stays active for every step after it, until either a later step sets its own (replacing the whole set) or a Run separately step starts a fresh browser with nothing set at all. In practice this means you usually only need to set an auth header once — on whichever step first needs it — not on every step that happens to navigate.
• {{VARIABLE}} interpolation only substitutes text — it doesn't encode anything for you. HTTP Basic Auth needs the value Basic <base64 of "user:password">, not Basic user:password. If you're building this from environment variables, store the already base64-encoded string as a single Environment variable and reference that (e.g. Authorization: {{BASIC_AUTH_HEADER}}), rather than trying to compose it from separate username/password variables at the header field.
• Variables only resolve if an Environment is actually selected for the run (the "Env:" dropdown next to Run Suite, and the same dropdown feeds Test Connection below). If none is selected, {{VARIABLE}} is left as literal text in the header — which usually means the request fails in a way that's easy to misread as a header-format problem when it's actually a missing-environment problem.

Test Connection

Below the step editor, Test Connection navigates a real browser to the step's Starting URL with its configured headers, and shows you the resulting screenshot — the UI Workflow equivalent of the Response preview on API Workflow steps. Use it to confirm you're actually getting past whatever's in front of your target (an auth wall, a maintenance page) before running the whole suite.

Run separately

Each "Go to URL" step has a checkbox: Run separately.

By default, steps share one browser session across the whole suite run — that's what lets a step that logs in carry its session into a later step that expects to already be signed in, without re-authenticating every time. Checking this box forks a brand-new, completely separate browser for that step — no cookies, no local storage, no headers carried over from anything else in the run — and every step after it (Continue or Go to URL) picks up from that fork instead of wherever the suite was before. There's no going back to the earlier session once a step forks; think of it as a clean break in the chain, not a temporary detour.

Because a forked step touches nothing shared with the rest of the suite, it's also free to run at the same time as other independent parts of it, instead of waiting its turn — which can meaningfully speed up a suite made up of several unrelated flows.

Use it when a step's flow is genuinely self-contained and doesn't rely on (or want) whatever session state exists elsewhere in the suite — testing a second user logging in alongside the first, or an unauthenticated flow you want to be sure isn't accidentally inheriting a login from earlier in the run. Leave it unchecked for a step that's meant to continue from what an earlier step set up — including a later step that isn't immediately next to it, as long as nothing in between forked away from it.

If a step needs a value another step extracted, it still waits for that step regardless of this setting — a real data dependency always takes priority over the isolation/parallelism choice.

When a step can't find what it's looking for

If a step's action can't be carried out — most often because the page doesn't have whatever it was told to interact with — the step is marked Blocked in results, along with a screenshot of the page as it actually looked at that moment (when one could be captured) and the error message. Use it to see directly whether the app was in an unexpected state, rather than working from the error text alone.

A blocked step doesn't automatically mean the whole run shows no verdict — see Objective for how a run's overall pass/fail is decided when some steps are clean and others aren't.