V
Vibeview
Pricing
Sign In

Sub-Flows

Reuse a recorded test case as a prerequisite for other test cases. Define common flows like login or profile selection once, attach them to any number of test cases, and update them in one place.

What’s a sub-flow?

A sub-flow is a regular test case marked reusable. When a test case has sub-flows attached, the sub-flow steps run before the test case’s own steps — both in standalone runs and inside a suite. Sub-flows carry their own recording and visual baselines, so:

  • Replay mode plays back the sub-flow’s recorded actions deterministically. No tokens spent re-deciding how to log in.
  • Hybrid mode replays the sub-flow’s recording and falls back to AI only if the screen drifts from the recording.
  • Pure AI mode treats the sub-flow’s steps as natural-language instructions, same as today.
  • Visual regression baselines live on the sub-flow itself. Re-baseline once, every consumer picks it up on the next run.

Creating a sub-flow

Sub-flows are always standalone test cases — they don’t live inside a suite. The flow is:

  1. Record a test case in the device sandbox.
  2. In the save modal, choose Save as standalone (instead of picking or auto-creating a suite).
  3. Open the saved case’s detail page → toggle Reusable sub-flow on.

The case now appears in the Sub-Flows tab on /tests and in every other test case’s sub-flow picker.

Why standalone-only? A sub-flow runs before other tests, not as a regular suite case. If the same case were both a suite case AND a sub-flow attached to other cases in the same suite, it would execute twice per run. The API enforces is_reusable=true requires no parent suite to prevent this.

You can toggle it off at any time. Test cases that already attached this sub-flow will fail at the start of their next run with a clear error — re-attach a different sub-flow or remove the reference to fix.

Attaching a sub-flow to a test case

  1. Open the consumer test case.
  2. Click Attach Sub-flow in the Sub-flows section.
  3. Pick from the list of reusable cases in your organization.
  4. Order matters: sub-flows run in the order they were attached, before the consumer’s own steps.

When the consumer runs:

  • Standalone: subflow1 -> subflow2 -> consumer.
  • In a suite: each case still runs subflow1 -> ... -> consumer, with the suite’s reset strategy (relaunch / clear_data / reinstall) running between cases.

Updating a sub-flow

Re-record the sub-flow, edit its steps, or re-baseline its screenshots — every consumer test case picks up the change on its next run with no further action.

There is no “snapshot” of the sub-flow embedded in consumers; the consumer’s sub_flow_ids is just a list of pointers, resolved fresh at every run.

API reference

A sub-flow is a regular test case, so the existing /api/v1/tests/cases/{id} endpoints apply.

Promote a test case

PATCH /api/v1/tests/cases/{case_id}
{ "is_reusable": true }

The API returns 400 if the case has a parent suite — move it out first or record it as standalone.

List reusable cases (sub-flow picker)

GET /api/v1/tests/cases/reusable

Returns every reusable test case in the caller’s organization.

Attach sub-flows to a consumer

PATCH /api/v1/tests/cases/{consumer_case_id}
{ "sub_flow_ids": ["login-abc123", "select-profile-def456"] }

The backend rejects sub_flow_ids entries that are missing, not reusable, in another organization, equal to the consumer itself, or duplicated. Attempting to attach a non-reusable case returns 400.

Limitations (v1)

  • No nested sub-flows. A reusable case attached as a sub-flow may not itself attach further sub-flows — the run rejects the configuration with a clear error.
  • No after-each / teardown sub-flows. The suite’s reset strategy handles inter-case cleanup.
  • Single device frame. Sub-flow recordings are scaled using the consumer’s source device dimensions; mixing wildly different screen sizes between a sub-flow and a consumer may produce coordinate drift in replay mode (AI fallback still works).