Back to compare picker

Change review vs Review before submit vs Approval workflow vs Review queue vs Comments vs Compare view vs Version history vs Activity log vs Permission denied state

Choose change review when the primary object is a proposed edit, diff hunk, tracked change, suggested change, or file change that a reviewer can inspect and then accept, reject, apply, batch, mark viewed, comment on, or request changes for.

Decision dimensions

Dimension Change reviewReview before submitApproval workflowReview queueCommentsCompare viewVersion historyActivity logPermission denied state
UI or UX UI + UX - Review surface for proposed edits, diffs, tracked changes, or suggestions before they become accepted contentUI + UX - Final editable answer summary before committing a transactionUI + UX - Routed decision workflow for requests that require authorized approvalUI + UX - Actionable queue for triaging many items that need human reviewUI + UX - Object-attached comment composer and comment list with authorship, replies, state, permissions, and moderationUI + UX - Selected side-by-side attribute comparison of peer itemsUI + UX - Durable snapshot browser for previous document, file, page, object, or configuration versionsUI + UX - Searchable and exportable record of system, user, or administrative eventsUI + UX - Authorization and access-boundary state
UI guidance Render change review around a concrete proposed change with base content, proposed content, changed scope, author, timestamp, reviewer progress, pending comment state, accept, reject, apply, batch, and submit-review actions.Render a single review page immediately before commit with a clear title, grouped answer sections, readable key/value rows, per-answer or per-section Change actions, skipped optional answers when meaningful, and a primary button whose label names the committed action.Render approval workflow as a routed request record with requester, object, requested action, approver eligibility, required rule, current gate, due date, decision controls, comment history, and outcome consequences.Render review queue as an actionable worklist with queue scope, counts, filters, sort order, row reason, owner, priority, age or SLA, status, preview context, selection, and row actions.Render comments as anchored contributions with author identity, timestamp, body, optional attachment or selection context, edited state, reply target, and state labels such as open, resolved, hidden, deleted, or assigned.Render compared items as a bounded side-by-side matrix with item identity, thumbnail or icon when useful, price or status, remove controls, action controls, grouped attribute rows, row labels, consistent units, missing-value notation, and difference indicators.Render version history as a durable snapshot browser with the current version, previous version list, author, timestamp, named version labels, autosaved version labels, changed summary, retention status, compare affordance, preview, and restore action.Render activity logs as evidence-oriented records with event time, actor, action, object, source system, scope, result, and technical context such as IP address or location when available.Show the blocked object or action, current account, permission level, required role, owner, and request path when revealing that information is allowed.
UX guidance Use change review when users need to inspect edits from another person or tool, understand impact, discuss or suggest fixes, and decide whether changes are accepted, rejected, requested, batched, or sent back for revision.Use review before submit to give users one final chance to verify and correct captured answers before a transaction is sent, paid, published, applied, or otherwise committed.Use approval workflow when a submitted request cannot proceed until an authorized person, group, threshold, sequence, or external policy gate explicitly approves or rejects it.Use review queue when a team repeatedly processes a changing set of tickets, comments, pull requests, content items, cases, requests, or records that require human inspection and action.Use comments when users need to discuss, question, annotate, review, or leave follow-up notes on a specific object, selection, file line, record, document, or task without changing the primary content directly.Use Compare view when users have selected a small set of similar items and need to weigh several meaningful attributes together before choosing, saving, buying, applying, or discarding options.Use version history when users need to find a known good state, understand what changed between saved states, recover from bad edits, cite a prior version, name a meaningful milestone, or restore content without guessing.Use activity log when users need to investigate, audit, verify, or troubleshoot actions across accounts, objects, systems, settings, or security boundaries.Use permission denied state when the system knows the user is authenticated but their role, group, share, license, policy, or approval status blocks a specific object or action.
Good UI A document review pane highlights one suggested sentence, shows original and proposed text, author, comment, Accept, Reject, Previous, Next, and Preview accepted controls.A claim review page has Applicant, Contact details, Evidence, and Declaration sections; each row shows the captured answer and a Change link with hidden context such as Change email address.A production deployment request shows requester, service, environment, change summary, required reviewer group, self-review restriction, wait timer, Approve and Reject with reason controls, and a timeline of route changes.A support queue shows New triage, SLA at risk, owner, customer, status, priority, age, preview text, assignment, and next actions without opening every ticket.A document margin comment shows the selected paragraph, author, timestamp, body text, Reply, Resolve, Assign, and Copy link actions with the composer focused on that selection.A laptop compare view shows three selected models as columns, grouped rows for performance, display, portability, and support, a sticky model header with price, and a differences-only switch.A document side panel marks v42 as Current, lists v41, v38 named Pre-launch copy, and v35 autosaved, and opens a compare preview before Restore this version.An organization audit log table shows timestamp, actor, action, target object, app, IP address, result, and a Details drawer with before and after fields.A report page says Quarterly revenue report requires Finance viewer access, shows the current account, names the report owner, and offers Request access and Switch account.
Bad UI A page lists Changed item with Approve and Reject buttons but no original text, proposed text, author, scope, or consequence.A final page says Check your answers but shows only a paragraph and a Continue button with no answers, section headings, or change links.A request page says Waiting without naming the approver, required count, due date, or escalation path.A review queue shows a flat list of titles with no reason, age, owner, status, priority, or action controls.A Notes textarea sits under a record and calls itself comments even though every user overwrites the same field.A comparison page shows seven products in tiny columns with paragraphs in every cell, no row grouping, no sticky headers, and no way to remove one item.A History panel lists Edited, Edited, Edited with no version number, author, content preview, compare result, or restore consequence.A page titled Activity shows vague entries such as Changed settings with no actor, target, timestamp, or source.A denial page says Something went wrong and shows Retry even though the user lacks a required group.
Good UX A reviewer moves through tracked changes one by one, accepts a terminology fix, rejects a risky deletion with a reason, sees the next unresolved change, and submits the review summary.A user changes their phone number from review, lands on the phone page with the old value pre-filled, saves, and returns directly to review with other answers preserved.A requester submits a deployment, sees it is waiting for Release managers, cannot self-approve, receives a change request with a required comment, edits the change summary, and resubmits to the same route.A reviewer claims the oldest SLA-at-risk ticket, opens a preview, assigns it to Billing, returns to the queue with the row removed, and lands on the next oldest item.A reviewer comments on a selected line, adds an action item for Dana, receives a reply, resolves the comment, and can reopen it from the resolved filter.A shopper selects three laptops, opens comparison, hides identical specs, highlights battery and memory differences, removes the weakest option, and returns to the same shortlist in the product grid.A designer names the last approved file version, compares it against the current version, confirms restore, and sees that the restore created v43 while keeping v42 available.An admin filters to failed SSO events, expands one entry, copies the event ID, exports the filtered range, and sees that records older than 180 days require a different archive.A user opens a restricted report, sees which account is signed in, requests viewer access with a reason, then sees that the request is pending with the owner.
Bad UX A reviewer writes several pending comments but never submits the review because the UI makes draft comments look published.A user selects Change address, edits one field, then has to repeat every later page before finding the review page again.The first approver clicks Approve and the system marks the whole request approved even though policy required everyone to approve.Two reviewers open the same unclaimed item, both act, and the second decision overwrites the first with no stale-row warning.A user writes a long comment, loses network connection, and the draft disappears when the page reloads.A user must open three product detail pages in separate tabs and remember battery, weight, and warranty values because the site has no comparison view.A user tries to recover yesterday's copy but only sees a chronological activity log with no previewable previous version.A user marks a notification read and the corresponding activity evidence disappears from the only log.The app returns a blank screen for a restricted file, so the user cannot tell whether the file is gone, private, or opened with the wrong account.
Best fit Users inspect and decide on proposed edits, tracked changes, code suggestions, file diffs, or document redlines.A user has provided multiple answers and should verify them before a consequential submit action.A submitted request needs authorized approval before a deployment, purchase, access grant, publication, content change, policy exception, financial action, or workflow step can proceed.A team or individual repeatedly reviews many independently queued items.Users need object-attached discussion without changing the primary object content directly.Users need to choose among similar offerings using multiple comparable attributes.Users edit documents, files, pages, design files, records, configurations, or published content over time.Users need to inspect recorded user, admin, system, security, or integration events.A signed-in user lacks permission to view, edit, publish, export, delete, approve, share, administer, or configure a resource.
Avoid when The user only checks their own answers before a transaction.The task is a single low-risk field with clear inline validation and an obvious submit action.The user only needs to check their own answers before submission.The task is a single request moving through a governed approval route.The user is simply entering a long answer into a form field.Items are unique, nonexclusive, too simple, too cheap, or mostly aesthetic.The product only has an event log with no saved content snapshots.The goal is only to show a readable milestone history for one case or process.The user is not signed in and the next step is authentication rather than authorization.
Required state Default change review state with original and proposed content visible.Initial review state with grouped captured answers, relevant sections, and explicit submit action.Draft or submit-ready request handoff stateQueue loading and count stateEmpty comment list and first-comment composer.No compared items state with instructions for adding items and a route back to browse.Default state with current version, previous version list, author, timestamp, and change summary.Default log state with event records, result count, visible timezone, retention window, and permission scope.Whole-object access denied state.
Accessibility burden Expose insertion, deletion, replacement, original text, proposed text, author, and status as text, not color alone.Use headings that make the review task explicit, such as Check your answers before sending your application.Use labelled request summary, approver, status, due date, decision, comment, and history regions.Use labelled queue name, count, filters, sort, group, row status, selection, preview, and action controls.Label the comments region with the object or selection being discussed.Expose comparison title, selected item count, maximum item count, item names, row labels, group headings, units, and missing-value meanings as text.Use structured list, table, or tab semantics so version number, current status, author, timestamp, and label are read together.Use table or structured list semantics so actor, action, object, timestamp, result, and scope are perceivable together.Use a heading that identifies the access boundary and a text description that does not rely on lock icons or red color alone.
Common misuse Showing accept and reject controls without original and proposed content.Using a review page that contains no captured answers.Showing a generic pending message without the approver, gate, rule, or due date.Using an ordinary table with no review reason, urgency, ownership, or decision actions.Using one shared Notes field as a comment system and overwriting prior contributors.Allowing too many compared items so columns become unreadable.Calling an activity log or audit trail version history when it has no previous content snapshots.Calling a social feed or notification drawer an activity log without event evidence.Treating authorization denial as a generic retryable error.

Change review

UI or UX
UI + UX - Review surface for proposed edits, diffs, tracked changes, or suggestions before they become accepted content
UI guidance
Render change review around a concrete proposed change with base content, proposed content, changed scope, author, timestamp, reviewer progress, pending comment state, accept, reject, apply, batch, and submit-review actions.
UX guidance
Use change review when users need to inspect edits from another person or tool, understand impact, discuss or suggest fixes, and decide whether changes are accepted, rejected, requested, batched, or sent back for revision.
Good UI
A document review pane highlights one suggested sentence, shows original and proposed text, author, comment, Accept, Reject, Previous, Next, and Preview accepted controls.
Bad UI
A page lists Changed item with Approve and Reject buttons but no original text, proposed text, author, scope, or consequence.
Good UX
A reviewer moves through tracked changes one by one, accepts a terminology fix, rejects a risky deletion with a reason, sees the next unresolved change, and submits the review summary.
Bad UX
A reviewer writes several pending comments but never submits the review because the UI makes draft comments look published.
Best fit
Users inspect and decide on proposed edits, tracked changes, code suggestions, file diffs, or document redlines.
Avoid when
The user only checks their own answers before a transaction.
Required state
Default change review state with original and proposed content visible.
Accessibility burden
Expose insertion, deletion, replacement, original text, proposed text, author, and status as text, not color alone.
Common misuse
Showing accept and reject controls without original and proposed content.

Review before submit

UI or UX
UI + UX - Final editable answer summary before committing a transaction
UI guidance
Render a single review page immediately before commit with a clear title, grouped answer sections, readable key/value rows, per-answer or per-section Change actions, skipped optional answers when meaningful, and a primary button whose label names the committed action.
UX guidance
Use review before submit to give users one final chance to verify and correct captured answers before a transaction is sent, paid, published, applied, or otherwise committed.
Good UI
A claim review page has Applicant, Contact details, Evidence, and Declaration sections; each row shows the captured answer and a Change link with hidden context such as Change email address.
Bad UI
A final page says Check your answers but shows only a paragraph and a Continue button with no answers, section headings, or change links.
Good UX
A user changes their phone number from review, lands on the phone page with the old value pre-filled, saves, and returns directly to review with other answers preserved.
Bad UX
A user selects Change address, edits one field, then has to repeat every later page before finding the review page again.
Best fit
A user has provided multiple answers and should verify them before a consequential submit action.
Avoid when
The task is a single low-risk field with clear inline validation and an obvious submit action.
Required state
Initial review state with grouped captured answers, relevant sections, and explicit submit action.
Accessibility burden
Use headings that make the review task explicit, such as Check your answers before sending your application.
Common misuse
Using a review page that contains no captured answers.

Approval workflow

UI or UX
UI + UX - Routed decision workflow for requests that require authorized approval
UI guidance
Render approval workflow as a routed request record with requester, object, requested action, approver eligibility, required rule, current gate, due date, decision controls, comment history, and outcome consequences.
UX guidance
Use approval workflow when a submitted request cannot proceed until an authorized person, group, threshold, sequence, or external policy gate explicitly approves or rejects it.
Good UI
A production deployment request shows requester, service, environment, change summary, required reviewer group, self-review restriction, wait timer, Approve and Reject with reason controls, and a timeline of route changes.
Bad UI
A request page says Waiting without naming the approver, required count, due date, or escalation path.
Good UX
A requester submits a deployment, sees it is waiting for Release managers, cannot self-approve, receives a change request with a required comment, edits the change summary, and resubmits to the same route.
Bad UX
The first approver clicks Approve and the system marks the whole request approved even though policy required everyone to approve.
Best fit
A submitted request needs authorized approval before a deployment, purchase, access grant, publication, content change, policy exception, financial action, or workflow step can proceed.
Avoid when
The user only needs to check their own answers before submission.
Required state
Draft or submit-ready request handoff state
Accessibility burden
Use labelled request summary, approver, status, due date, decision, comment, and history regions.
Common misuse
Showing a generic pending message without the approver, gate, rule, or due date.

Review queue

UI or UX
UI + UX - Actionable queue for triaging many items that need human review
UI guidance
Render review queue as an actionable worklist with queue scope, counts, filters, sort order, row reason, owner, priority, age or SLA, status, preview context, selection, and row actions.
UX guidance
Use review queue when a team repeatedly processes a changing set of tickets, comments, pull requests, content items, cases, requests, or records that require human inspection and action.
Good UI
A support queue shows New triage, SLA at risk, owner, customer, status, priority, age, preview text, assignment, and next actions without opening every ticket.
Bad UI
A review queue shows a flat list of titles with no reason, age, owner, status, priority, or action controls.
Good UX
A reviewer claims the oldest SLA-at-risk ticket, opens a preview, assigns it to Billing, returns to the queue with the row removed, and lands on the next oldest item.
Bad UX
Two reviewers open the same unclaimed item, both act, and the second decision overwrites the first with no stale-row warning.
Best fit
A team or individual repeatedly reviews many independently queued items.
Avoid when
The task is a single request moving through a governed approval route.
Required state
Queue loading and count state
Accessibility burden
Use labelled queue name, count, filters, sort, group, row status, selection, preview, and action controls.
Common misuse
Using an ordinary table with no review reason, urgency, ownership, or decision actions.

Comments

UI or UX
UI + UX - Object-attached comment composer and comment list with authorship, replies, state, permissions, and moderation
UI guidance
Render comments as anchored contributions with author identity, timestamp, body, optional attachment or selection context, edited state, reply target, and state labels such as open, resolved, hidden, deleted, or assigned.
UX guidance
Use comments when users need to discuss, question, annotate, review, or leave follow-up notes on a specific object, selection, file line, record, document, or task without changing the primary content directly.
Good UI
A document margin comment shows the selected paragraph, author, timestamp, body text, Reply, Resolve, Assign, and Copy link actions with the composer focused on that selection.
Bad UI
A Notes textarea sits under a record and calls itself comments even though every user overwrites the same field.
Good UX
A reviewer comments on a selected line, adds an action item for Dana, receives a reply, resolves the comment, and can reopen it from the resolved filter.
Bad UX
A user writes a long comment, loses network connection, and the draft disappears when the page reloads.
Best fit
Users need object-attached discussion without changing the primary object content directly.
Avoid when
The user is simply entering a long answer into a form field.
Required state
Empty comment list and first-comment composer.
Accessibility burden
Label the comments region with the object or selection being discussed.
Common misuse
Using one shared Notes field as a comment system and overwriting prior contributors.

Compare view

UI or UX
UI + UX - Selected side-by-side attribute comparison of peer items
UI guidance
Render compared items as a bounded side-by-side matrix with item identity, thumbnail or icon when useful, price or status, remove controls, action controls, grouped attribute rows, row labels, consistent units, missing-value notation, and difference indicators.
UX guidance
Use Compare view when users have selected a small set of similar items and need to weigh several meaningful attributes together before choosing, saving, buying, applying, or discarding options.
Good UI
A laptop compare view shows three selected models as columns, grouped rows for performance, display, portability, and support, a sticky model header with price, and a differences-only switch.
Bad UI
A comparison page shows seven products in tiny columns with paragraphs in every cell, no row grouping, no sticky headers, and no way to remove one item.
Good UX
A shopper selects three laptops, opens comparison, hides identical specs, highlights battery and memory differences, removes the weakest option, and returns to the same shortlist in the product grid.
Bad UX
A user must open three product detail pages in separate tabs and remember battery, weight, and warranty values because the site has no comparison view.
Best fit
Users need to choose among similar offerings using multiple comparable attributes.
Avoid when
Items are unique, nonexclusive, too simple, too cheap, or mostly aesthetic.
Required state
No compared items state with instructions for adding items and a route back to browse.
Accessibility burden
Expose comparison title, selected item count, maximum item count, item names, row labels, group headings, units, and missing-value meanings as text.
Common misuse
Allowing too many compared items so columns become unreadable.

Version history

UI or UX
UI + UX - Durable snapshot browser for previous document, file, page, object, or configuration versions
UI guidance
Render version history as a durable snapshot browser with the current version, previous version list, author, timestamp, named version labels, autosaved version labels, changed summary, retention status, compare affordance, preview, and restore action.
UX guidance
Use version history when users need to find a known good state, understand what changed between saved states, recover from bad edits, cite a prior version, name a meaningful milestone, or restore content without guessing.
Good UI
A document side panel marks v42 as Current, lists v41, v38 named Pre-launch copy, and v35 autosaved, and opens a compare preview before Restore this version.
Bad UI
A History panel lists Edited, Edited, Edited with no version number, author, content preview, compare result, or restore consequence.
Good UX
A designer names the last approved file version, compares it against the current version, confirms restore, and sees that the restore created v43 while keeping v42 available.
Bad UX
A user tries to recover yesterday's copy but only sees a chronological activity log with no previewable previous version.
Best fit
Users edit documents, files, pages, design files, records, configurations, or published content over time.
Avoid when
The product only has an event log with no saved content snapshots.
Required state
Default state with current version, previous version list, author, timestamp, and change summary.
Accessibility burden
Use structured list, table, or tab semantics so version number, current status, author, timestamp, and label are read together.
Common misuse
Calling an activity log or audit trail version history when it has no previous content snapshots.

Activity log

UI or UX
UI + UX - Searchable and exportable record of system, user, or administrative events
UI guidance
Render activity logs as evidence-oriented records with event time, actor, action, object, source system, scope, result, and technical context such as IP address or location when available.
UX guidance
Use activity log when users need to investigate, audit, verify, or troubleshoot actions across accounts, objects, systems, settings, or security boundaries.
Good UI
An organization audit log table shows timestamp, actor, action, target object, app, IP address, result, and a Details drawer with before and after fields.
Bad UI
A page titled Activity shows vague entries such as Changed settings with no actor, target, timestamp, or source.
Good UX
An admin filters to failed SSO events, expands one entry, copies the event ID, exports the filtered range, and sees that records older than 180 days require a different archive.
Bad UX
A user marks a notification read and the corresponding activity evidence disappears from the only log.
Best fit
Users need to inspect recorded user, admin, system, security, or integration events.
Avoid when
The goal is only to show a readable milestone history for one case or process.
Required state
Default log state with event records, result count, visible timezone, retention window, and permission scope.
Accessibility burden
Use table or structured list semantics so actor, action, object, timestamp, result, and scope are perceivable together.
Common misuse
Calling a social feed or notification drawer an activity log without event evidence.

Permission denied state

UI or UX
UI + UX - Authorization and access-boundary state
UI guidance
Show the blocked object or action, current account, permission level, required role, owner, and request path when revealing that information is allowed.
UX guidance
Use permission denied state when the system knows the user is authenticated but their role, group, share, license, policy, or approval status blocks a specific object or action.
Good UI
A report page says Quarterly revenue report requires Finance viewer access, shows the current account, names the report owner, and offers Request access and Switch account.
Bad UI
A denial page says Something went wrong and shows Retry even though the user lacks a required group.
Good UX
A user opens a restricted report, sees which account is signed in, requests viewer access with a reason, then sees that the request is pending with the owner.
Bad UX
The app returns a blank screen for a restricted file, so the user cannot tell whether the file is gone, private, or opened with the wrong account.
Best fit
A signed-in user lacks permission to view, edit, publish, export, delete, approve, share, administer, or configure a resource.
Avoid when
The user is not signed in and the next step is authentication rather than authorization.
Required state
Whole-object access denied state.
Accessibility burden
Use a heading that identifies the access boundary and a text description that does not rely on lock icons or red color alone.
Common misuse
Treating authorization denial as a generic retryable error.
Decision rules
  • Choose change review when the primary object is a proposed edit, diff hunk, tracked change, suggested change, or file change that a reviewer can inspect and then accept, reject, apply, batch, mark viewed, comment on, or request changes for.
  • Choose review before submit when the same user is checking their own captured answers immediately before committing a transaction; there is no external proposed edit or reviewer decision about another change set.
  • Choose approval workflow when a submitted request needs authorized approvers, required counts, route state, due date, rejection, requested changes, delegation, timeout, or downstream blocking.
  • Choose review queue when reviewers process many independently queued items and need workload controls such as row reason, owner, SLA, claim, skip, bulk action, and next-item focus.
  • Use comments to discuss a proposed change, ask questions, or explain a decision; comments support change review but do not replace the accept, reject, apply, viewed, and stale-change states.
  • Use compare view when the user only needs side-by-side comparison of alternatives; change review adds decision state and proposed-change lifecycle on top of comparison.
  • Use version history when users browse durable previous snapshots; change review concerns pending or proposed changes before they become accepted current content.
  • Use activity log after decisions happen to record who accepted, rejected, applied, requested changes, or dismissed a suggestion; it is not the decision surface.
  • Use permission-denied state when a user can see a change but cannot accept, reject, apply, or submit review because ownership, branch, document, or role permissions do not allow it.
  • A change review surface must label base versus proposed content, changed scope, reviewer progress, pending comments, suggestion status, accept or reject consequence, batch scope, stale or outdated state, and final submission state.
Inspect live examples
Failure modes
  • A reviewer cannot tell whether they are accepting one suggestion, all visible suggestions, or every hidden change.
  • Accepting a proposed change applies stale content after the underlying file, paragraph, or branch changed.
  • The UI shows a visual diff but provides no explicit review decision state or next unresolved change.
  • Pending review comments are mistaken for submitted feedback because draft and submitted states look identical.
  • Rejecting a suggestion deletes reviewer rationale or hides the dismissed change from audit.
  • A read-only reviewer sees Apply suggestion or Accept change controls that will fail after click.