Skip to main content

Understand Flock

Review types, goals, and inputs

A useful review starts with a clear question and the right setup. Here is what each control means, what Flock detects, and what you need to provide.

Choose the review that answers your question

Open New Review → Guided on a desktop-sized browser. These are the starting options:

  • Single Page Run: analyze the starting page without navigation. Useful for pricing clarity, a confusing form, or a focused design review.
  • Roam: explore through multiple steps. Useful for finding unclear paths, unexpected detours, and friction between screens.
  • Goal: define an outcome and choose This page only or Follow the flow. Useful when you can describe what the reviewer should accomplish.
  • Create Run via Prompt: import a structured setup brief. Inspect the imported goal and remaining setup steps before launch; this control expects the supported structured format.

Design Reviewer is an option in the persona selector when available. It is not a fifth goal type. If you select it, the dashboard can offer an approved design baseline for comparison. Customer personas and specialist auditors answer different questions; see personas.

Optional design baseline initially selects the approved workspace default when one exists. Choose another approved version or None — observed consistency — no approved design system. A baseline pins a reference version; a retired or unavailable selection needs validation before launch. Design Reviewer is a billable persona execution, and its expert observations are counted separately from user findings.

The four goal types

All four types use the same goal, completion, boundary, and input controls. The type describes the intended outcome and changes the suggested boundaries and automatic flow limits. It does not supply the task or your application’s test data for you.

  • Transactional: complete checkout or a subscription. Example: choose an annual plan and reach the test checkout confirmation. Suggested boundaries include avoiding real payment information and real account emails.
  • Form Completion: submit signup, setup, or profile forms. Example: create a test account and reach the welcome screen. Suggested boundaries include avoiding personal information and real addresses.
  • Discovery: find information or compare options. Example: find the plan that includes team access and explain its price. Suggested boundaries include not starting a trial or creating an account.
  • Support: find help or submit a ticket. Example: find the documented refund process. Suggested boundaries include not submitting real tickets or sharing personal data.

Suggested boundaries are choices you add to the setup. Review them against the task you actually intend to run.

Scope, task, and completion

This page only judges the goal on the starting page. Follow the flow allows navigation when the goal needs steps. A task that requires a confirmation screen should generally use Follow the flow.

In What should the agent try to accomplish?, describe one specific outcome. The statement supports up to 1,000 characters. “Finish onboarding with a test account” is more useful than “test onboarding.”

Completion criteria supply objective signals. You can add up to eight, each with a value of up to 1,000 characters:

  • Content contains: visible rendered text contains the supplied phrase, such as Welcome to your workspace.
  • URL matches: the current URL matches the supplied wildcard pattern, such as **/welcome*.
  • Element visible: a matching CSS selector is visible, such as [data-goal-complete].
  • Request succeeds: a captured request URL matches the wildcard pattern and has a 2xx response, such as **/api/signup*.

Any one matching criterion can mark the goal achieved. These are alternative finish signals, not a checklist that requires every item. Avoid broad criteria that are already true on the starting screen. A successful request also needs to represent the outcome you care about; it does not necessarily mean the whole journey is complete.

Boundaries describe what the reviewer should avoid. Add up to eight, each up to 1,000 characters. For a discovery review, “stop before creating an account” makes the task’s intended stopping point clear. Boundaries are instructions to the reviewer; review the observed actions and outcome afterward.

Goal reviews with Follow the flow choose their initial limits automatically:

  • Transactional and Form Completion: 10 agent actions, 12 page hops, and 600 seconds.
  • Discovery and Support: 5 agent actions, 6 page hops, and 300 seconds.

These are caps, not promised run lengths. A review can finish earlier. In Customize step limits, enable Custom to set Max agent actions from 1–12, Max page hops from 1–15, and Time budget from 15–900 seconds. Single-page reviews do not use these navigation controls.

Quick Roam starts with the standard 5-action, 6-hop, 300-second budget. Its Target step exposes Roam budgets for adjustment. Keep a repeat review’s limits comparable so a longer exploration does not masquerade as a product change.

Goal inputs

Goal inputs are domain-specific values the reviewer should use or choose during the task. Add up to 50 fields. The Signup, Bank signup, Checkout, and Settings templates provide editable starting fields; they do not detect your product’s form or guarantee that a generated value meets its rules.

Each field has a Key, Label, Type, and Source. Keys must be unique and use a lowercase letter followed by lowercase letters, digits, or underscores, such as signup_email. Labels give the reviewer a readable description. Types are Text, Number, Boolean, Null, and List; the list value control accepts comma-separated items.

Choose a source that fits what you want to learn:

  • Use this value: supply the value yourself. Choose Reusable when future attempts can use it again, or One-time when it will be consumed or expire. One-time inputs make Run again and Schedule unavailable until the setup is repaired.
  • Let reviewer choose: leave the choice to the reviewer in context. This is useful for preferences such as a plan, region, or shipping speed. The choice is cleared for a fresh attempt rather than treated as fixed test data.
  • Generate value: generate an email plus-address or password. Generated fields use text values and are locked. Email generation requires a Base email and can use a Tag prefix; the password is shown as generated rather than exposed as a literal setup value.

Locked tells the reviewer to preserve a supplied value. It is available for values you supply; reviewer-choice fields are unlocked and generated fields are locked automatically. Generated values are assigned when a run attempt is launched, rather than copied from the displayed draft.

For signup, use a test email address whose service accepts plus-addressing, add a generated password, and define a completion signal on the actual welcome screen. Flock’s generator does not establish that your application accepts the address or password.

JSON import/export lets you inspect or reuse the structured input definition. Edit the displayed JSON and choose Import JSON to apply it, or Refresh JSON to restore the current field configuration. Imported definitions are validated before launch.

Target inputs and automatic detection

In Target URL, enter an HTTP or HTTPS URL, or a domain; the dashboard adds https:// to a bare domain. The hosted browser must be able to reach the target. A localhost URL refers to the runtime’s own machine, so connect a reachable preview or staging deployment for local development work.

Environment is detected from hostname labels, such as staging.example.com or pr-42.example.com, and can be edited. The detector does not classify the environment from a path or query string. Target classification can remain Automatic or be corrected to Production or Non-production. Production targets require the workspace owner or admin acknowledgement shown in the setup.

Target URL setup values inspects the URL for values that may be sensitive, variable, or unsuitable for replay. This is URL analysis, not a scan of the target screen or its form fields. When Flock needs a choice, the dashboard shows the detected location and supported classifications:

  • One-time: use it once; Run again and Schedule become unavailable.
  • Reusable: keep the same value for later runs, when it really stays valid.
  • Generated: bind it to supported generated setup data. Some choices require a generated email goal input first.
  • Normal URL: treat an eligible value as ordinary routing data. Detected sensitive values cannot use this choice.

For an unidentified variable segment, the choices explain whether it is a reusable invite code, one-time secret, generated value, or static URL part. Resolve the displayed questions before relying on replay. Flock’s detection is a prompt to check the setup, not proof that a link is safe to reuse.

Under Advanced: Deployment context, optional Build ID, Commit SHA, and Branch describe which build you are reviewing. They provide context; entering a commit SHA does not deploy that commit or change the target URL.

Personas, sign-in, and launch

In Personas, choose the available profiles or population configuration. Availability and limits depend on the workspace. The persona guide explains traits, workspace forks, populations, and specialist reviewers.

In Auth, choose the saved sign-in required by the target, or review a public target. Saved sign-in is managed in Settings → Integrations. Flock account access and target application sign-in are separate. A valid session today may need repair before a later scheduled review.

No auth starts with clean browser state. Saved sign-in offers active profiles, with unavailable or different-app profiles disabled. The selector can initially choose the first ready profile when no compatible one is selected, so inspect the actual sign-in choice rather than assuming it stays blank.

In Review, check the target, task and scope, completion signals, boundaries, input policies, personas, authentication, limits, and usage estimate. Resolve the readiness requirements, then choose Launch Review. Imported or restored setups still need this inspection; the dashboard does not infer your intended outcome from the target screen.

After launch, inspect the task outcome, scores, and evidence, then triage the findings. To repeat a useful setup over time, read scheduled reviews.