Run Detail

The run detail page is a v2 command centre with four tabs — Overview, Cases, Issues, and Activity. A linear breadcrumb header shows the run id, editable title, meta chips, and lifecycle actions. Press Esc or click the back arrow to return to the list.

When the run will not open

If the run cannot be loaded, the page says which kind of problem it is and stops, rather than sitting on a spinner. There are three of these, and only one of them is worth retrying.

A connection wobble is retried for you first. The page makes up to three attempts before showing Could not load. A definitive answer from the server — deleted, forbidden, or a malformed link — is not retried at all, so those two states appear immediately.

An already-loaded run stays on screen. If a background refresh fails while you are working, the run you are looking at is kept rather than replaced by an error page.

Being denied the View test runs permission outright is a different screen again, and reads You do not have permission to view this run.

Think of it as mission control

The header is the status board — run id, title, progress bar, and lifecycle actions. Overview is the health dashboard. Cases is where testers execute — inline result buttons, a side panel, a full-screen focus runner, or the per-case runner route. Issues answers two questions side by side — what broke (Defects) and what the run was meant to prove (Requirements). Activity is the day-by-day commentary feed.

Header

• Breadcrumb — a linear crumb ending in TR-… ⋯. The ··· menu on the terminal crumb is the single home for run actions — there is no separate title-row actions menu. On an open run it holds Edit run…, Edit cases…, Re-run failed & blocked, Close run…, Duplicate run, and Delete run…. Edit cases… is the only way to change which cases are in the run: it leaves this page for the test case repository and reopens the Run Composer against this run. On a closed run, Edit run, Edit cases and Close drop out and Reopen run takes Close’s place, alongside Re-run failed & blocked, Duplicate run, and Delete run… These run actions need the Create test runs permission; Delete needs Delete test runs.
• Title — editable inline when you have Create test runs permission (read-only on a closed run).
• Meta chips — lifecycle state, cycle link, environment, tags, contributor avatars, and percent executed.
• Progress bar — segmented status distribution with completed-out-of-total count, shown in the tab strip.

Closing and reopening a run. There is a single Close run… action, and it lives only in the crumb ··· menu — there is no duplicate title-row Close button and no separate “Mark completed”. Closing is server-guarded (never optimistic): if any case failed without a linked defect the close guard prompts first, and the close freezes a sign-off snapshot. A closed run shows a read-only banner across the header, carrying a Reopen run button for users with the Create test runs permission. See Managing Runs.

Overview tab

The default tab. A two-column layout summarises run health and metadata.

Cases tab

The primary execution workspace. Lists every test case in the run with its current result, assignee, and folder path.

Toolbar

The toolbar is split into a left scope cluster and a right controls cluster:

• Folder jumper — scope the list to one of the run’s own folders (or Ungrouped) without leaving the page. All cases clears the scope.
• Quick-filter chips — All, Untested, Failed · Blocked, and Mine (cases assigned to you). Each chip shows a live count.
• Search — filter cases by title within the run. Press Enter to apply; the search runs on the server and refetches.
• Filter — opens a two-pane fly-out with multi-select property filters (keyboard shortcut f). The field pane has a type-to-find box and splits into Built-in and Custom fields sections. Active selections appear as removable chips in a rail below the toolbar.
• Display — a popover that leads with the list / table / board view control, then grouping (Folder — the default — Tester, Status, Linked issue, Requirement (covers), or no grouping) and ordering (Run order — the default — Status, Case ID, or Title, with an ascending/descending toggle). The grouping and ordering menus are admin-driven: each of your workspace’s enabled single-select custom fields (for example Priority or Severity) is appended as its own grouping and ordering option, in the admin-defined field order; past ten entries they gain a type-to-find box. In list view it adds a Result entry control (Inline or Panel); for list and board it also exposes display-property chips to show or hide trailing fields. The chips are split into two sections: Built-in — State, Folder, Template, Labels, Requirements, Linked issues, Updated, Result, Tester, and Executions, of which only Linked issues, Tester and Executions are on by default — and Custom fields, one chip per enabled run-relevant custom property field, in admin order. Long-form TEXT fields are not offered here — a paragraph cannot be a trailing chip — they render as prose blocks on the case instead. Newly enabled custom fields are shown by default. When an admin disables a field it drops out of the popover automatically, and any grouping, ordering, or chip preference that referenced it falls back to a default. Every option is a client-side view preference.
• Views — list is the fast execution stream, board renders one column per active Display grouping (Folder by default), and table adds a column manager in its header for choosing and ordering columns (in table view the Display popover points you there).
• Focus — opens a full-screen, keyboard-first runner for one case at a time.

Case property filters

Click the filter button to open the fly-out. Options are derived from the cases already loaded in the run — only values that exist in the run appear. Selections combine with AND across fields and OR within a field, and apply instantly.

The fly-out lists seven built-in facets:

The last two are different in kind from the rest: their values are the tracker issues themselves, listed by key and title with the issue’s own status glyph, rather than a fixed vocabulary read off the rows. Pick one to narrow the run to just the cases touching it.

“No linked issue” and “No requirement” are separate questions, not opposites. A case can carry both kinds of link, one, or neither, and the same ticket can be linked to a case as a defect and as a requirement. So a case can legitimately appear under a Requirements value while also matching No linked issue — it covers something, but nothing broke on it.

Below them, a Custom fields section adds one facet per enabled option-typed custom field your administrator defined — dropdown, multi-select, and checkbox fields (for example Priority, Severity, or Automation). Free-text, date, number, and link fields are display-only and are not offered as facets, because their values do not form a finite checklist.

• Values are the options actually present on the run’s loaded cases, listed in the admin-defined option order.
• A multi-select field contributes every selected option, and a case matches if it carries any of the values you tick.
• If a field is later disabled, its facet simply disappears and a filter that referenced it stops narrowing the list rather than breaking it.

Grouping by linked issue or requirement

Grouping by Linked issue or Requirement works differently from grouping by Folder or Tester, because a case can have several of each. A case covering two requirements appears under both — that is the point: the group answers “what is the state of everything touching this ticket?”, and a case that touches two tickets is genuinely part of both stories.

• Each group header counts its own rows, so the group counts deliberately add up to more than the number of cases in the run. The toolbar’s N cases always shows the true distinct count.
• Keyboard navigation, select all, and the panel/focus running order all visit each case once, in reading order, however many groups it appears in. You will not be walked through the same case twice.
• Cases with nothing linked collect in a trailing group — No linked issue or No requirement covered.

The grouped value is not repeated on the rows

When the list or board is grouped, the group header becomes the only place that value is shown, and it drops off every row and card beneath it. Grouped by Folder, no row shows a folder chip; grouped by a custom field, none shows that field’s chip. It removes a column of identical text from every row in the group and leaves the chips that actually vary.

Three refinements are worth knowing:

• Grouped by Linked issue or Requirement (covers), only that ticket key leaves the chip — other linked issues still show, and the two relations are treated separately, so a case that covers the same ticket it is grouped under as a defect keeps its Requirements chip.
• Grouped by Status, only the opt-in Result label chip is hidden. The leading result glyph and the right-hand quick strip stay put — those are how you record a result, not decoration.
• Grouped by Tester, nothing is hidden. The tester slot is the assign picker, and removing it would take away the only way to reassign from that view. The rule dedupes a displayed value; it never removes a control.

Table view is the deliberate exception — cells keep the value. A blanked cell is indistinguishable from the em dash a genuinely empty one draws, and the column stays there either way, so hiding it would trade a harmless repetition for a real ambiguity and free no space at all.

On the board a suppressed chip is never drawn, so it does not eat into a card’s two-line chip budget or its +N count — the freed slot goes to something that differs between cards. All of this is display-only: your display-property choices are untouched, and turning grouping off brings every chip straight back.

Table columns

In table view, the header’s column manager chooses which field columns are shown and in what order (ID and Title are fixed). The shown list reorders with the up/down controls and hides with the ✕; the available list below is split into Available · built-in (Result, Tester, Folder, Template, Labels, Linked issues, Requirements, Updated) and Custom fields — one column per enabled custom property field, in admin order. Long-form TEXT fields are excluded: at column width they would be blank or an ellipsis, so they render as prose blocks on the case instead. Past twelve columns the available list gains a type-to-find box. Option-typed custom-field columns also sort from their header. Default columns are Result, Tester, Folder, and Linked issues; a saved column that points at a since-disabled field — or at a TEXT field — is dropped automatically. Requirements is available but off by default, so teams not doing coverage tracing do not pay for a column they never use.

The Linked issues and Requirements columns are two halves of the same information, split by what the link means: Linked issues shows defects and unclassified links, Requirements shows what the case covers. Each renders the first key with a +N for the rest, and the count always matches the keys behind it. The same ticket can legitimately show in both columns when it is linked to the case under two relations.

However far you scroll a wide table sideways, the column manager button stays pinned to the right edge of the header rather than scrolling out of reach.

Execution

• Inline result buttons — tap a status button on any row to record that outcome instantly. The UI updates immediately and syncs in the background (see the workspace header Sync pill).
• Panel mode — set Result entry to Panel in the Display control, then click a row (or press Enter) to open a side detail panel with the case’s steps, a rich-text result note, the result buttons, and result history.
• Focus mode — the toolbar Focus button (or F on an active row) opens a full-screen, keyboard-first runner. See Recording Results.
• Per-case runner — open a single case in its own route for step-by-step execution with prev/next navigation. See Recording Results.
• Assignee picker — change who owns a case directly on the row.
• Multi-select + bulk bar — select cases to open a floating bar at the bottom of the viewport with an accent N cases chip (clear with the inline ✕ or Esc), then Assign or Set result menus to stamp one assignee or one status across the selection (Set result also offers Clear result), plus a Remove from run action that takes the cases out of the run while preserving their result history. See Recording Results.
• Fail→issue prompt — when you mark a case Failed or Blocked and it has no linked tracker issue, a non-blocking prompt offers to raise or link an issue. Dismiss it twice in a row and the per-case prompting stops, replaced by a single standing N failures with no linked issue chip. See Recording Results.

On a closed run the whole Cases tab is read-only: no inline result strip, no assignee picker, no selection checkboxes, and no Focus action. Reopen the run to record again — see Reopening a run.

Cases load in pages of 100 — use Load more to fetch the next page. The folder scope, quick filters, property filters, grouping, and ordering are all client-side over the loaded rows (no refetch); only the title search refetches from the server. See Recording Results for execution details.

Issues tab

Two questions, two scopes, chosen with the toggle at the top of the tab:

• Defects — what broke while running. Tracker issues linked from this run’s results, deduped by issue key and ranked open-first. This is the default scope.
• Requirements — what the run’s cases exist to verify. Tickets linked to those cases with a Covers requirement relation, each with the cases covering it and a coverage verdict. See Requirements view.

Each button carries a live count.

Why a link shows up under Defects when it is not called “Defect”. The split is between coverage and everything else, not between the relation named Defect and the rest. On a stock workspace most relations — Relates to, Verifies, Blocks — carry the General semantic, and a Defects list that showed only Defect-semantic links would hide most of what your team has actually linked. General links are surfaced here rather than dropped, and flagged as unclassified so you can classify them. See Relations.

Defects

Failed and blocked cases with linked defects surface here alongside issues raised from the fail→issue prompt.

• Needs-triage strip — when any failed or blocked case has no linked tracker issue, a standing queue appears at the top listing each case with a Link issue action (attach an existing tracker issue) and a + New issue action. The strip disappears once every red result is triaged.
• Lifecycle facet — All, Open, or Resolved (with open/resolved counts).
• Expandable rows — expand a row to reveal which cases in this run link to that issue.
• Row badges — rows carry status-rich badges: Re-test (tracker fixed but red cases remain), Verified (fixed and all linked cases passed), a blocks/case-count badge, and a cross-run reach badge (+N · TR-…) when the same issue is linked from other runs, with the run name on hover.

Creating issues. + New issue opens an in-place composer. When the selected tracker supports in-app create (for example Linear), Create issue posts the draft directly and a row appears immediately while the tracker assigns the key in the background (shown as ··· until synced). For trackers without write support, Create in <tracker> opens the tracker’s new-issue page with a seeded title; link the fresh key back with the search box. Creating or linking requires the Manage external references permission.

A create the tracker rejects never disappears. If the tracker refuses the create — a validation error, a rate limit, an outage — the row stays on the list instead of vanishing, so you are never left believing a defect was filed when none exists. It shows failed in red where the issue key would be, reads create failed — not in <tracker> when expanded, and carries a Retry create action on the row and in the expanded card that replays your original draft. Open in <tracker> is inert on such a row, because no issue exists there to open. The retained row survives a refresh of the issue list and a full page reload — it is kept in this browser, scoped to this workspace, project, and run, for up to seven days — so closing the tab does not quietly discard the obligation. A successful retry clears it, and signing out clears every retained row from that browser, since the drafts hold text you wrote.

Click a row’s linked case to jump back to the Cases tab. Linked defects also appear on the parent cycle’s Issues tab.

Requirements view

One row per requirement ticket the run’s cases cover, with its tracker key, title, and a verdict chip. Expand a row to see which cases cover it and how each of them ended.

The verdict is derived from results in this run only — a pass the same case earned in a different run is never borrowed, because a requirement is only verified by the testing you actually did here. The four verdicts are shared with the cycle Issues tab, so Cycles and Runs can never say different words about the same requirement:

“Success” and “failure” here are the flags your administrator set on each status, not its name — a custom status called Passed w/ exceptions verifies a requirement, and one called Env down puts it at risk. See Status Properties.

Requirement links are read-only in a run: coverage is authored on the test case, so there is nothing here to add or remove. Link a requirement from the case itself — see Relations.

Requirement coverage (Overview card)

The Overview tab summarises the same data in one card: <n> of <total> requirements verified, a percentage, and a bar split into Verified, At risk, and Not verified yet.

The denominator is the requirements this run’s cases link to — not the number of cases, and not every requirement in the project. A run that covers three tickets is measured against three, however many cases do the covering.

• If links exist but none are classified as coverage, the card reads 0 of 0 requirements verified with No relation set, so nothing counts as coverage yet and a Classify links action. That honesty is deliberate — unclassified links are not quietly counted as coverage.
• The card does not render at all while its data is still loading or unavailable, rather than showing a provisional number. A card is an assertion.
• When there is nothing to say — no requirements and no unclassified links — it stays hidden.

Activity tab

A day-grouped feed of run events — result recordings, case reassignments, run metadata edits, and run-lifecycle events. Each day header shows how many events occurred that day. A 7d / 14d / 30d range toggle (default 14d) scopes the recent-change summary; older events load on demand with Load more.

Closing and reopening a run are recorded here as lifecycle rows attributed to the person who did it: … closed this run — signed off & snapshot captured, and … reopened this run for edits, each with the sign-off snapshot it captured or preserved. The wording carries the meaning on its own, so the rows read correctly without relying on their colour or icon.

Background saves. Result and assignment changes on the Cases tab apply to the UI immediately. The workspace header Sync pill shows whether changes have reached the server. If sync fails, use Retry on the pill or the toast.

Your own edits show up right away. Recording results, reassigning cases, linking or raising issues, and run metadata edits refresh the Issues and Activity tabs as soon as you open them — no hard refresh needed. Changes made by other testers while you have the run open may still need a refresh to appear.