# Session review

A human-review queue for sessions: rules flag the sessions worth a look, and your team works through them as open, ignored, or done.

**Session review** is a work queue for humans. Rules decide which sessions someone should read; matching sessions land in a queue your team works through, instead of being spotted by whoever happened to be browsing.

:::info
Session review is off by default, and the planner that fills the queue also requires **Tasks** to be enabled. If the page is missing, or the queue stays empty with enabled rules in place, [contact us](mailto:support@brizz.ai) — neither is a setting an organization admin can change.
:::

## What it is

**Rules** decide which sessions get flagged. The **queue** is where they wait for a person. It's deliberately separate from [Issues](/docs/platform/issues.md): an issue is a problem Brizz detected and clustered, while a review is a session a human asked to look at — a healthy session can still be worth reviewing.

## How it's populated

A rule is a set of filter conditions over sessions, drawn from a subset of the [Sessions](/docs/platform/sessions.md) filters. A planner runs periodically and applies every enabled rule across a recent lookback window, so items arrive in batches rather than the moment a session finishes. A session matched by several rules is queued once, and each run adds at most 1,000 matches per rule. Rules can be disabled without deleting them.

## How to read it in the dashboard

Three tabs: **Open** (waiting), **Ignored** (looked at, set aside), and **Done**. You can mark an open item done or ignore it, and reopen a closed one — no decision is final.

Each rule carries a name, an optional description, its conditions, and an enabled switch. Managing rules requires **admin** or higher; anyone with page access can work the queue.

## How to act on it

1. **Write rules for sessions you'd read anyway.** "Negative feedback" or "errors on the new model" are good; "all sessions" recreates the Sessions page with extra steps. A rule isn't scoped to one service, so put the narrowing in the conditions.
2. **Keep Open drainable.** A queue nobody can finish stops being read — tighten the rule rather than working harder.
3. **Ignore deliberately.** Lots of ignores on one rule means it's over-matching.
4. **Raise an issue when a review finds a pattern.** The queue is for individual sessions; a recurring problem belongs in [Issues](/docs/platform/issues.md).

## Tasks

The **Tasks** page is the landing page for "what needs my attention", combining pending reviews with open issues seen in the last week. Both lists are capped, so it's a shortlist rather than a full inventory. Depending on your navigation layout it may replace the Issues entry or sit beside it.

## Availability

Off by default for both the queue and Tasks, and enabled by Brizz rather than by an organization admin. Creating and editing rules requires **admin** or higher.

## See also

- [Sessions](/docs/platform/sessions.md) — the filters a rule is built from, and where a flagged session opens.
- [Issues](/docs/platform/issues.md) — the detected-and-clustered counterpart to a human queue.