# Test runs

> Create, execute, and close test runs; track time and results.

A **test run** is an execution session: you pick a set of test cases, snapshot
them into the run, and record the outcome of each one. Runs live under a
project — open the **Runs** entry in the project sidebar.

## Creating a run

1. On the Runs screen, click **New test run**.
2. Fill in the **Details** section:
   - **Title** (required) — pre-filled with a default of `Test run YYYY/MM/DD`
     (today's date, e.g. `Test run 2026/07/29`), fully editable before
     creating the run.
   - **Description** (optional). It can hold formatting and images.
   - **Environment** — pick from the history of environments already used in
     this project, or type a new free-form value (e.g. `Staging`, `v2-preview`).
   - **Default assignee** — the member assigned to every case in the run that
     has no per-case assignee. If left empty, the first person to open a case
     is assigned automatically.
   - **Milestone** — visible but not yet functional (coming soon).
3. In the **Test cases** section, choose **From repository** (the only active
   source; **From test plan** is a coming-soon stub) and click **Add cases** to
   open the case-selection modal.
4. In the case-selection modal:
   - Browse the suite tree on the left to filter the case table by suite.
   - Use the search box and filter bar (Status, Priority, Tag) to narrow the list.
   - Check the cases to include. Use **Select all** to check every case currently
     visible after search and filters.
   - Optionally set a **per-case assignee** using the dropdown in the Assigned
     column. A per-case assignee overrides the run default for that case only.
   - Click **Done** to return the selection to the run creation modal. Zero
     cases is allowed at this step; the run itself needs at least one (step 6).
5. The selected cases appear grouped by suite in the Test cases section.
   Click **×** on any row to remove a case before creating the run. At least
   one case must remain — the **Create** button is disabled at zero cases.
6. Click **Create**. The run opens ready to execute.

If the project lets only approved test cases into runs (a
[test case review](https://docs.probara.net/en/guides/test-case-review/#only-approved-cases-in-runs) option), the
case-selection modal lists only approved cases, and the dialog asks you to remove any selected case
that is not approved before creating the run.

A parameterized case appears in the selection with **× N**, its number of combinations, and the dialog shows how many run cases the selection creates in total. Each combination becomes its own run case, with its own status and results. See [Parameterized test cases](https://docs.probara.net/en/guides/parameterized-test-cases/).

On a narrow (phone-width) screen, the **Environment**/**Milestone** pair and
the **Configurations** fields lay out in a single column instead of side by
side — the same fields, in the same order, just stacked. The **Edit run**
modal (below) shares this layout.

The case-selection modal (step 4) also presents one pane at a time there. The
case list comes first, and the suite tree is one level in, behind a **Suites**
bar at the top naming the suite the list is narrowed to. Tapping that bar opens
the full-width suite list, where **Select all** and each suite's own checkbox
behave exactly as they do on a wider screen; tapping a suite narrows the list
and returns to it, and the **✕** beside the bar clears the narrowing in one
tap.

Inside that list the rows follow the width the list itself has, which is what
your suite rail leaves behind — so widening the rail can re-shape them at any
screen size. While the list is roomy it is the five-column table: checkbox,
priority, ID, title, assignee. Once it is narrower than a case title needs,
each case becomes a ruled entry instead — checkbox, priority and ID on one
line, then the title and its own assignee control full width beneath it — and
the column labels give way to a **Select all shown** control. Nothing is
hidden either way, and at tablet width and above the suite tree and the case
table stay side by side.

> **BREAKING change (API):** `POST /api/v1/projects/:projectId/runs` now
> requires `caseUlids` to be a non-empty array (`minItems: 1`). Requests with
> `caseUlids: []` or without `caseUlids` return `422 validation_failed`. If
> you were creating empty runs via the API and adding cases later via
> `POST /runs/:runUlid/cases`, update your workflow: include at least one case
> in the initial `POST /runs` request.
>
> **Exception for CI tools:** `automated: true` allows creating a run without
> cases: send it and omit `caseUlids`, then report results into the run with
> `POST /api/v1/projects/:projectId/reports` and `run: { ulid }` — one run that
> every CI shard reports into. The flag never removes cases: cases from
> `caseUlids` or `planUlid` are still added. It is request-only (not stored),
> and `caseUlids: []` is still rejected. The **New test run** dialog keeps
> requiring at least one case.

**Assignee resolution order** (per case): per-case assignee set in the
case-selection modal → run default assignee → unassigned (null).

When a case is added to a run, the run keeps the [version](https://docs.probara.net/en/guides/test-repository/#version-history)
of the case it had at that moment: its title, fields, and steps are
**snapshotted** into the run. Editing the original case in the repository
afterwards does not change the run on its own, and closed runs never change.
A [shared step](https://docs.probara.net/en/guides/shared-steps/) in the case is snapshotted as the
steps it holds at that moment; editing or deleting it later leaves the run
unchanged.

#### When a case changes during a run

While the run is open, a case still waiting to be executed (untested, or retried)
that was edited in the repository after it was added shows a violet history
icon (a clock with a back arrow) next to its title, and **Case updated** in the
case panel; hover the icon to see which version the run has and which is the
latest. A
case that already has a result keeps the version it was executed with and shows
no notice. To run the latest version instead, click **Apply latest version** in
the case panel or the row's actions menu, or **Apply latest to all pending
cases** in the run's actions menu. This is only possible before any step of the
current attempt has a result. To update a completed case, retry it first:
earlier attempts keep the title, steps, step results and attachments they were
executed with, so every recorded result still matches them.

A parameterized case updates one run case at a time. **Apply latest version** on a run case takes the latest version of the case for that run case's combination. If the combination no longer exists in the latest version, the run refuses the update: remove that run case, or add the case to the run again to get its current combinations. **Apply latest to all pending cases** updates the run cases it can, and names the ones it skips and why. See [Parameterized test cases](https://docs.probara.net/en/guides/parameterized-test-cases/).

### Creating a run from a repository selection

You can skip the case-selection modal entirely by starting from an existing
selection in the **Test repository**:

1. Check one or more cases (or a whole suite band) using the bulk-selection
   checkboxes.
2. In the bulk-action bar, click **Run**.
3. The Runs screen opens with the new-run modal already open and your
   selected cases preselected in the **Test cases** section.
4. Add or remove cases as needed, fill in the run details, and click
   **Create**.

The repository selection itself is unaffected by Run — it stays as-is so you
can start another bulk action afterward.

### Launching a run in GitHub Actions

With the [GitHub integration](https://docs.probara.net/en/guides/integrations/github/) connected, **Run in GitHub Actions**
on the Runs screen creates an automated run and starts your test workflow on the branch you choose.
The run shows the build's status, link and duration, and the reporters send the results into it.
See [Running tests with GitHub Actions](https://docs.probara.net/en/guides/integrations/github-actions/).

## The runs list view

The Runs screen presents every run in the project as a table with eight
columns:

- **Title** — the run's reference (`R-12`) and name, with the date it was
  started underneath.
- **Environment** — free-text label captured at creation time (e.g. `Staging`,
  `Production`). Runs without an environment show an em-dash (`—`).
- **Configurations** — the run's tagged configuration values (e.g. `Chrome /
Windows`), joined by `/`. A run with no configurations shows an em-dash.
  Since the default run name is now date-based rather than combination-based
  (see "Creating a run" below), this column is what tells apart several runs
  created the same day. The same column appears, unchanged, on a test plan's
  runs section and on a milestone's runs tab.
- **Author** — who triggered the run. For runs created from the web app, this
  is the user's name and avatar. For runs created from the API (CI/CD), it is
  the API token's name displayed with the key icon used elsewhere in the
  Activity feed; for runs reported by an
  [app token](https://docs.probara.net/en/guides/integrations/junit-xml/), the app's logo and name
  beside the token name, such as **JUnit XML · nightly-ci**. Legacy runs whose original author cannot be recovered show an
  em-dash.
- **Total time** — the cumulative sum of the individual durations of every
  case that has been executed in the run so far.
- **Elapsed** — the wall-clock interval between the first and last result
  registered on the run. For runs still in progress this value ticks every
  second so you can watch it advance live.
- **Status** — the projected label (In progress / Passed / Failed) — see
  below.
- **Results** — a stacked horizontal bar showing how the cases break down
  across the five per-case statuses (passed / failed / blocked / skipped /
  untested), with the executed/total count and pass rate below.

On a narrow (phone-width) screen the list presents the same runs as a stack of
ruled entries instead of a table: each entry leads with the run's title, then
lists the environment, configurations, author, total time, elapsed, status, and
results underneath. Every value, filter, and action you have on a wider screen is
still there — only the layout changes. At tablet width and above the list is
the ruled table described here.

The filter bar above the table combines search, a permanent **Status** chip, and
additional filters from **Add filter**:

- Search filters by run name or environment substring (case-insensitive).
- **Status** is an always-present chip (no **×**, never offered in **Add
  filter**). Open its popover editor to check **In progress**, **Passed**, and/or
  **Failed** — combine them to show multiple projected statuses, or leave it empty.
- **Environment** uses the environments already seen in this project. You can
  select more than one value.
- **Author** filters to user-authored runs. Runs created by API tokens stay
  visible in the table but are not matched by a user author filter.
- **Default assignee** filters by the run's default assignee, including
  **(empty)** for runs without one.
- **Run custom fields** — **Add filter** also lists this project's filterable
  `test_run` custom fields (options, checkbox, and member picker; free-text and
  numeric fields are not filterable and never appear here). Each editor offers an
  **(empty)** choice for runs with no stored value for that field. Custom filters
  are evaluated against **stored value rows only**; a default shown on the run's
  detail page does not satisfy a filter until a value is actually saved.

Active filters appear as removable chips and are reflected in the URL so you can
share a filtered view. A `N of M` counter on the right reflects the filtered
state, and **Clear filters** removes search and chips together.

## Run status labels

Each run shows a single badge that reflects both whether execution is still open
and the overall outcome:

- **In progress** — the run is still open; you can keep marking cases.
- **Passed** — the run is closed and every case outcome is passing (including
  skipped cases; untested-only closes still count as passed when there are no
  failures).
- **Failed** — the run is closed and at least one case failed or was blocked.

The same badge appears on the runs list and in the execution view header.

## Executing a run

The execution screen is a **board grouped by suite**: each suite collapses into
a band with its own progress bar, aggregate duration, case count, and the
snapshotted suite name. Cases without a suite live under a "Cases without
suite" band. A **search box** at the top filters cases by title or short ID
across every band.

A right-side **summary rail** shows the run's overall progress: a donut
(executed vs. total), a status legend, and metadata fields including the
**Estimate** — a forecast of how long the run should take, computed from the
average elapsed time of the same cases in prior runs of the project. When no
case has any history the estimate renders as an em-dash (`—`).

On a phone or tablet (below 1024px) the rail is not a column. A **Summary** band
sits directly under the page header carrying the headline readout — percent
executed, the executed/total count, the failure count when there is one, and the
current state — and activating it opens the whole rail as a bottom sheet. No
value is dropped; only the number of taps to reach it changes.

If the project has run custom fields configured, the rail also shows a **Run
custom fields** block, positioned between **Elapsed** and **Tags**. This block is **read-only** — to
change a value, use the Custom fields
section in the create or edit run modal (see "Run custom fields" below). A
field with no stored value shows its configured default, or an em-dash when
it has no default. The block is omitted entirely when the project has no run
custom fields.

Linked defects are not in the rail. They have their own **Defects** tab, between
**Test cases** and **Activity**. Each row shows the defect's `D-<n>` reference,
title, status, severity, priority, and assignee. Click a row to open the defect.
On a shared link the rows are plain text.

## Resizing and collapsing the summary panel

On a desktop screen (1024px and wider) the rail is a real panel whose width you
set yourself. Drag its **leading edge** — dragging left widens the rail and
dragging right narrows it. With the handle focused you can also step the width
with `ArrowLeft` (wider) and `ArrowRight` (narrower), and **double-click** it to
restore the panel's default width.

The **round chevron button on the panel's left edge** — shown when you point at the panel or tab to it — or the `]` key collapses it. Collapsed, the rail becomes
a 56px readout column: the progress ring, the completion percentage and the
executed/total count stay, a hairline separates them from a rack of icon keys,
and each key opens that section's values in a popover anchored beside the column.
Collapsing removes no value — every section is one click deeper. Activating the
same toggle, in the same place, brings the panel back.

**The width and the collapsed state are shared by all four summary panels** —
runs, test plans, milestones and defects. Resize the run panel and the plan,
milestone and defect panels render at the same width; collapse one and the other
three render collapsed too, including after a reload and after navigating to
another surface. Expanding any one of them expands the others.

These controls exist only on a desktop screen. On a phone or tablet the summary
stays the **Summary** band and its sheet, described above.

Open a case to switch the rail for a **slide-over execution panel**: case
short-id, title, the snapshotted description / pre-conditions / post-conditions
(only the conditions the project has enabled are shown), and the steps. Each
step has its own per-step Pass / Fail / Skip / Block band and a collapsible
**Data / Expected result** card — click the chevron to reveal **Data** and
**Expected result** stacked inside the body. A Gherkin step has no expected result: its card shows its keyword before its text, and an **Argument** in place of **Data**. Marking a step reveals its
**Actual result** field without forcing that disclosure open or closed. It
can hold formatting and images: to show what happened, paste an image into it,
drop it there, or type **/** and choose **Image**. The actual result is saved automatically — there is no
explicit Save button.

Steps that come from a [shared step](https://docs.probara.net/en/guides/shared-steps/) are ordinary
steps of the case, each with its own number and no label: a run shows them
exactly like any other step, and each one is marked on its own.

A **Case result** control is docked at the bottom of the **Execution** tab.
Use it to mark the entire case Pass / Fail / Skip / Block. This is the
case-level outcome that records an entry in the **Retries** tab (with a frozen
per-step snapshot you can reopen later). Per-step marks update the live
workspace immediately and appear in the project **Activity** feed, but they do
**not** create an entry in the Retries tab on their own.

Cases that already have a terminal result (Passed, Failed, Skipped, or Blocked)
open in a **readonly consultative view**: the Case result control is not
present, step marks are read-only, and the panel shows a **Defects** tab
(linked defects filed during the attempt) and a metadata rail with
who executed the case, when it started, how long it took, and when it finished.

For a case with that terminal result, the panel header leads the case title
with a compact **result mark** — a small status glyph in a tinted circle — in
place of the result chip that used to sit beside the case short-id. This
applies on every surface: the slide-over panel, the full-screen view, and the
read-only attempt panel opened from the Retries tab. The mark is icon-only; the retest
count is not shown in the header. A case that is still untested, or was just
reset via Retry, shows no header result indicator.

The panel header includes an **expand control** (⤢) that opens a full-screen
view of the same case content. Press **Escape** or click the collapse control
(⤡) in the top-right corner of the full-screen view to return to the
slide-over panel. The close control (✕) beside it, or a click outside the
full-screen view, closes the case instead; the next case you open comes back
full-screen.

### Case navigator in the full-screen view

When the full-screen view opens, a **case navigator** appears as a left-side
rail. The navigator lists every case in the run, grouped by suite; each suite
group shows its own mini progress chart, and each case row shows the compact
**result mark** described above (a dashed neutral ring for untested cases).

- **Search** the navigator with its own search field — this filter applies only
  to the navigator list and never changes the board's filters or the page URL.
- Click any case row to switch the main panel to that case. The breadcrumb and
  content update; the timer for the previously open case is preserved. The
  **Retries** and **Defects** tabs show that case's own attempts and linked
  defects; its attempts are listed only, so open the case from the board to
  view one.
- The currently displayed case is highlighted with a pressed state in the list.
- The navigator is view-only: selecting a case here does not automatically
  assign it to you.

Other things to know:

- The board's bulk-action toolbar offers **Submit result**, **Assign** (set or
  clear the assignee of the selected cases), **Retry** (reset the selected cases
  to `untested`) and **Remove** (delete them from the run); they are hidden only
  on an **aborted** run — a completed (closed, non-aborted) run keeps them
  available. See
  [Run selection bar](https://docs.probara.net/en/guides/runs/execution-panel/#run-selection-bar).
- A **timer** still starts when you open a case and stops when you mark it.
- Marking steps does not set the case's status: mark the case in the **Case
  result** band. The step bar above the steps counts the steps you marked and
  the ones that failed.
- Run metadata (state, started-by, environment, started-at, total time,
  elapsed) lives in the summary rail; the rail is hidden whenever a case panel
  is open.

### Executing on a narrow (phone-width) screen

Executing is a first-class phone flow — nothing about it is read-only or
scaled back. On a narrow screen:

- Each case row **stacks** instead of showing a single line: the title leads
  on its own line so it is never truncated to unreadability, and its status,
  assignee, and accumulated time arrange below it. The row stacks whenever the
  board itself is too narrow for the one-line layout — which depends on more
  than the window: collapsing the project rail widens the board and can bring
  the one-line row back at the same window size. Marking, assigning,
  filtering, search, selection and bulk actions, per-case actions, retry,
  remove, the Activity tab, and the run's overflow menu all stay reachable —
  none of them are hidden to make room. Suite bands keep their hierarchy and
  tri-state selection exactly as on a wider screen. A run's full case list
  always renders, however many cases it has — nothing is paginated away or
  held back to keep the board fast on a phone.
- Opening a case presents the execution panel **full-screen** instead of as a
  side panel: the case body, step and case-level marking, tabs, auto-advance,
  the save indicator, and the **Escape**-to-close gesture all work the same
  way. The resize handle and the expand-to-full-screen control are not shown
  — the panel already fills the screen, so there is nothing to expand into.
  Advancing to the next case after marking still scrolls that case's row into
  view behind the panel and moves keyboard focus onto it, exactly as on a
  wider screen.
- The docked **Case result** control keeps clear of the device's home
  indicator and any on-screen browser chrome at the bottom of the screen, and
  each of its keys presents a comfortably large touch target.
- The run's own buttons (**Complete** and the run's overflow menu) sit in the
  bar at the bottom of the screen. While a case is open they step aside, so
  the **Case result** control is the only thing docked there.

### Case status icon during execution

While executing a run, the board shows a small icon at the far right of each
case row when the case's **Status** is not Active. This is the same indicator
shown in the test repository.

Key points:

- The icon reflects the case's **current** status in the repository — not the
  snapshotted state captured when the run was created. If the status changes
  after a case is added to the run, the icon updates accordingly.
- Active status and unset status show nothing. Only non-Active options (Draft,
  Deprecated, or a custom non-active option with an icon) trigger the indicator.
- This differs from other case data (title, steps) which **are** snapshotted
  at the time of adding the case and never change regardless of edits to the
  source case.

## Closing a run

A run **closes itself automatically** the instant every case carries a result
— there is nothing to click. Once the last untested (or retest) case is marked,
Probara closes the run immediately and the runs list reflects it right away.

You can still click **Complete** to finish a run **early**, while untested
cases remain — a manual complete for when you are done testing but some cases
were never going to be run. If untested cases remain you are asked to confirm.
Complete never disappears just because auto-close exists: the two work
together, not as alternatives.

Closing — whether automatic or manual — is **not** the end of the run's story.
A closed, non-aborted run stays fully editable: you can still mark, retry, or
remove cases, add new cases, attach files, and edit results. The board
loses only the **Complete** button and the read-only banner shown for aborted
runs (see below); nothing else changes. Marking the last remaining case again
later never "reopens" the run — closing is a **one-way** state. If you retest a
case or add a fresh untested case inside a closed run, the run stays closed;
it never flips back to open on its own.

## Aborting a run

If a run needs to stop early — the scope changed, the build is unusable, or the
run was started by mistake — use **Abort run** from the overflow (**⋯**) menu on
the run detail page instead of Complete or Delete. Abort is only available
while the run is **open**; a completed or already-aborted run has no Abort
option.

Confirming abort in the destructive dialog (no reason field) freezes execution
immediately: the run closes, any cases still untested **stay untested** — abort
never records a result on your behalf — and existing results and attachments
are kept exactly as they were. The run shows an **Aborted** chip on the runs
list and can also be found with the **Aborted** Status filter option, alongside
In progress / Passed / Failed.

Unlike a completed (closed, non-aborted) run, an **aborted** run is
**terminal-frozen**: marking, retry, remove, adding cases, and attaching
files all stay disabled, and the board shows the read-only banner. If you
need to try again, use **Run again** (below) to clone a fresh run from it.

An aborted run still **counts as finished** for milestones and test plans — it
never blocks a milestone from auto-completing and never stalls a plan's
progress rollup — but its case counts (passed, failed, blocked, skipped,
untested) are **excluded** from milestone and test-plan progress numbers, so an
abandoned run does not skew what "done" looks like for the rest of the team.

## Data retention

Every run you create is kept **indefinitely by default** — there is no
automatic expiry unless your plan includes a retention window. If your
organization's plan includes one, runs (and everything they contain: cases,
steps, results, and attachments) that have been **closed or aborted** longer
than that window are removed automatically on a recurring schedule. A run that
is still **open** is never removed, no matter how old it is.

**This removal is permanent.** There is no undo, no recycle bin, and no
restore option — once a run's retention window has passed, it and its results
are gone. If you need to keep a run's history longer than your plan's window,
export or archive what you need before it ages out.

The same window applies to the **activity feed**: entries older than it are
deleted on the same schedule. A newer entry that referenced a removed run
stays; only its link to the run is cleared.

If you believe your organization's retention window is set incorrectly,
contact support — staff can grant, clear, or raise it on request.

## Editing a run

Use **Edit run** from the overflow (**⋯**) menu to change a run's descriptive
details or reselect its cases after creation. Edit is only available while the
run is **open**; a completed or aborted run has no Edit option.

The **Edit run** modal reuses the same fields as run creation — **Title**,
**Description**, **Environment**, and **Milestone** — pre-filled from the
run's current values. **Default assignee is not editable here**: it is a
one-time seed used only when the run is created, so the modal never shows it
and never sends it when you save. Per-case assignees remain the way to control
who works on a case after creation.

Clicking **Add cases** opens the same case-selection modal used at creation,
seeded with the run's current selection and per-case assignees — check or
uncheck cases and adjust assignees exactly as you would when creating a run.
Only the **repository** picker is available; sourcing cases from a test plan
is a creation-only flow. Saving persists your changes to the case selection
and the metadata fields together.

If your changes would remove one or more cases that already have a recorded
result or tracked time, Probara shows a **destructive confirmation** before
saving, naming how many cases are affected. Confirming proceeds with the save;
cancelling (or pressing Escape) leaves the run **completely untouched** — no
request is sent. Removing cases that are still untested with no tracked time
never triggers this extra confirmation.

**Results and tracked time are not recoverable.** If you remove a case that
was already executed and add it back later, it comes back as a fresh,
untested case — its prior result and time are gone for good.

## Run custom fields

If your organization has configured custom fields for the **Run** entity (see
[Custom fields](https://docs.probara.net/en/guides/workspace-custom-fields/)), both the run creation modal and
the **Edit run** modal show a **Custom fields** section, rendered with the
same field controls used elsewhere (short text, number, select, checkbox,
user picker, etc.).

- In the **create** modal, the section appears on the **From repository**
  tab only, pre-filled with each field's configured default value. **From
  test plan** never shows it and never sends any custom-field value with a
  generated run — plan-generated runs still receive each required field's
  default automatically, the same as any other run.
- In the **Edit run** modal, the section is pre-filled from the run's
  currently stored values (not from the field defaults), so editing a run
  never silently resets a value you already set.
- A required field left empty blocks the save and shows **This field is
  required** next to the control — no request is sent until every visible
  required field has a value.
- If the project has no visible run fields, neither modal shows the section
  at all.
- Closing either modal without saving discards any custom-field edits, the
  same as every other field on the form.

## Run configurations

If your project has configuration groups (see
[Configurations](https://docs.probara.net/en/guides/configurations/)) with live values, both the run
creation modal and the **Edit run** modal show a **Configurations** section —
one dropdown per group, offering at most one value.

- A group's dropdown includes a **No value** option, so a run can carry a
  value for some groups and none for others.
- In the **create** modal, the section appears on every tab and the chosen
  values are sent together with the rest of the run in a single request.
- In the **Edit run** modal, the section is pre-filled from the run's current
  configurations. Saving sends the new selection only when it actually
  changed; clearing every value and saving removes the run's configurations
  entirely.
- Editing configurations follows the same rule as every other metadata field:
  it works on an **open** run and on a **closed, non-aborted** run. An
  **aborted** run has no Edit option at all, so its configurations stay fixed.
- If the project has no configuration groups with live values, neither modal
  shows the section.
- Closing either modal without saving discards any unsaved configuration
  changes.

## Running a run again

There is no **Reopen** — once a run is closed (auto-closed, completed, or
aborted), it stays closed. To re-execute, use **Run again** from the overflow
(**⋯**) menu on any **closed** run (completed or aborted). It opens the
**Clone test run** dialog, which spins up a brand-new **open** run from the
finished one — the source run is never touched.

The dialog asks for:

- **Title** (required) — pre-filled as "_source run name_ (clone)"; edit it
  before confirming.
- **Clone with assignees** — when checked, each carried-over case keeps its
  assignee from the source run; when unchecked (the default), every case in
  the new run starts unassigned.
- **Case statuses to include** — a searchable multi-select of the six case
  outcomes (Untested, Retest, Passed, Failed, Skipped, Blocked). Leave it
  empty to carry over **every** case from the source run regardless of its
  last result; select one or more statuses to carry over only matching cases
  — the classic use is selecting Failed + Blocked to re-run just what broke.

## Adding a result and reporting a defect

Marking a case **Passed**, **Retest**, or **Skipped** advances immediately with
no modal — the mark and the silently-captured time are saved right away.

Marking a case **Failed** or **Blocked** opens the **Add result** modal
**before anything is saved** — the case stays untested until you confirm. In
the modal you can:

- Change the **Result** if you picked the wrong outcome — the select offers
  all four markable outcomes (Pass / Fail / Skip / Block). Switching to Pass
  or Skip hides the defect toggle and, on confirm, saves that outcome instead,
  carrying over any comment, time, or attachments you already entered.
- Add a **result comment** describing what happened. It can hold formatting
  and images: paste or drop an image into it, or type **/** and choose
  **Image**.
- Review and, if needed, adjust the **recorded time** for the attempt. It is
  a segmented hours, minutes, and seconds field with visible unit labels,
  seeded with the attempt's recorded time: edit it by typing or with the
  minus/plus buttons at the end of the field, and confirm with **Enter** or
  by leaving the field. A total may also be pasted, e.g. `2m 30s` or `45s`.
- Attach files (any type, up to the project's per-file and per-result limits)
  while the modal is still open — uploads happen in the background so
  Confirm stays fast.
- Decide whether to create or attach a defect, using a toggle that defaults
  **on** for a Failed/Blocked selection.

Selecting **Cancel** or pressing **Escape** on the Add result modal discards
everything: the case stays untested, nothing is saved, the stopwatch resumes
exactly where it was when the modal opened, and focus does not advance — it is
as if you never marked the case.

**Confirm** saves the selected result, comment, recorded time (the segmented
hours : minutes : seconds value), and attachments together as one action. With the defect toggle off, the case advances to the
next one. With the toggle on (only available for Fail/Block), Confirm opens
the **Report defect** modal against the newly saved attempt, with two tabs:

- **Create new** — file a fresh defect. The **description** starts
  pre-filled as formatted text from the case's failed steps (expected vs.
  actual result for each, with their images), so you rarely need to type it
  from scratch; it stays fully editable and can hold formatting and images.
  The composed headings (`Case:`, `Precondition:`, `Failed steps:`,
  `Expected:` / `Actual:`) are always in English by design, regardless of your
  interface language — this keeps defect descriptions consistent for teams
  that triage in a shared tracker. You can also set severity, priority, a
  milestone, and an assignee before creating it. On a narrow (phone-width)
  screen, the severity/priority pair and the milestone field lay out in a
  single column instead of side by side.
- **Attach existing** — select a defect you already filed, either from the
  suggested list (previously linked to this case) or by searching the
  project's defects, then press **Attach defect** to link it. Trying to
  attach with nothing selected shows an inline reminder instead of linking.
  Selecting a resolved or closed defect announces that confirming will reopen
  it; attaching links the attempt and reopens the defect together.

On either tab, check **Create another defect** to file or attach several
defects from the same attempt without leaving the modal — each successful
create or attach resets that tab and keeps the modal open.

Changed your mind after seeing the Report defect modal? Click the **back
arrow** next to the title to return to the Add result modal with everything
you entered intact — result, comment, time, and attachments. Re-confirming
only re-saves whatever you actually changed.

Use the retry dock's **Add defect** action on a locked case to open the Report
defect modal directly for that attempt, skipping the Add result step.

See [Defects](https://docs.probara.net/en/guides/defects/) for the project list and detail views.