Review queue

Problem Context

• Many items can independently enter and leave the queue based on status, assignment, SLA, requested review, moderation hold, reported content, code ownership, customer tier, priority, or workflow state.
• Reviewers often need to choose the next item, scan workload, process visible rows, avoid duplicate work, and recover when the underlying item changes.
• The queue may be personal, shared, team-scoped, role-restricted, saved, filtered, sorted, grouped, or ordered by SLA or priority.
• Actions may be low-risk triage such as assign or skip, or consequential review decisions such as approve, request changes, remove, reject, merge-block, publish-block, or escalate.

Selection Rules

• Choose review queue when the interface is primarily for processing multiple items that need review or triage over time.
• Use approval workflow when the focus is one submitted request and its governed route of required approvers.
• Use saved filter when the product only saves list criteria and does not provide review ownership, queue counts, row reasons, decision actions, or workload handling.
• Use activity log when users need to inspect past events rather than decide which queued item to handle next.
• Use notification center when reviewers need alerts, but route notifications into the queue or item rather than replacing queue state.
• Use table or list view when users are browsing records without review-specific state, assignment, SLA, or actions.
• Show queue membership reason, owner, age, priority, SLA or due state, review status, and source so reviewers can triage without opening every item.
• Support claim or assignment for shared queues when duplicate work is costly.
• Treat stale, already handled, reassigned, permission-limited, blocked, duplicate, and empty states as queue states with clear recovery.
• Require bulk-action previews for selected count, hidden filtered rows, stale rows, mixed eligibility, and irreversible outcomes.

Required States

• Queue loading and count state
• Filtered or grouped queue state
• Empty queue state
• Row preview state
• Claimed or assigned row state
• Unassigned row state
• SLA at risk or overdue row state
• Stale row changed since load state
• Selected rows and bulk-action preview state
• Action succeeded and row removed or moved state
• Skipped or snoozed row state
• Escalated or blocked row state
• Permission-limited row state
• Already reviewed by someone else state

Interaction Contract

• Queue membership is derived from canonical item state and refreshes counts when items enter, leave, or change status.
• Each row exposes why it is in the queue and enough context for safe triage before opening the full record.
• Opening a row preserves queue position, filter, sort, selection, and return context.
• Claim, assign, skip, snooze, escalate, approve, reject, remove, request changes, and mark reviewed actions update the canonical item and the queue row.
• Shared queues prevent or surface duplicate work through claim state, active reviewer state, stale-row warnings, or optimistic conflict checks.
• Bulk actions apply only to the previewed scope and report per-row exceptions for stale, ineligible, hidden, permission-limited, or already processed items.
• After a row action, focus moves to the updated row, next row, or queue status rather than resetting to the top without explanation.
• Notifications, reminders, and direct links open the matching queue, filtered queue, or item detail with current state.

Implementation Checklist

• Define queue sources, membership criteria, personal and shared scopes, row columns, sort order, grouping, count semantics, permissions, and stale-row detection.
• Model queue row state separately from item detail so the list can show reason, status, owner, age, priority, SLA, source, preview, and action eligibility.
• Implement filters, saved queue views, priority ordering, search within queue, selection, bulk preview, row preview, claim, assign, skip, snooze, escalate, and next-item navigation.
• Add conflict checks before row and bulk decisions to detect rows handled by someone else, changed since load, reassigned, or no longer eligible.
• Update counts, empty states, row positions, active filters, and focus after each decision.
• Show per-row failure and retry for failed actions instead of silently removing rows.
• Limit sensitive preview details by reviewer permission and provide safe disclosure when content cannot be shown in a shared queue.
• Test stale rows, concurrent reviewers, hidden filtered selection, mobile row wrapping, long titles, high counts, empty queues, permission-limited rows, keyboard action order, screen reader status updates, and bulk exceptions.

Common Generated-UI Mistakes

• Using an ordinary table with no review reason, urgency, ownership, or decision actions.
• Treating review queue as approval workflow and hiding many-item workload controls.
• Making queue counts stale after a row action.
• Allowing hidden rows to be bulk-processed without preview.
• Letting two reviewers unknowingly work the same row.
• Hiding SLA, age, priority, or source context needed for triage.
• Dropping reviewers back at the top after every item.
• Sending notification links to a generic dashboard instead of the queue or item.

Critique Questions

• Why is each row in this queue, and can reviewers see that reason before opening it?
• What tells reviewers which item should be handled next?
• Can reviewers claim, assign, skip, escalate, or bulk-process without losing scope clarity?
• How does the queue handle rows changed or completed by someone else?
• Do counts, filters, empty states, and focus update immediately after actions?
• Are notifications and saved views aligned with the canonical queue state?