Feedback & Review Workflow

The Feedback & Review Workflow turns a hosted preview into a browser-native review workspace. Visitors identify themselves with a name, optionally leave an email address, pin comments directly to visible page elements, submit several review items in one pass, answer inside item threads, request changes, approve required review slots, and move the preview through review rounds without leaving the browser. Submissions, review summaries, item threads, and decision history land in your Dashboard inbox and can also be read from the CLI or local mini-dashboard.

This feature is available on all paid plans (Individual and Teams).

How It Works

When you deploy a preview with --feedback, prev automatically injects a small JavaScript widget into the preview environment. The widget appears as a review flag on the right edge of the page. Visitors click it to open a full-height review sidebar where they can:

• Pin comments directly to visible DOM elements on the page
• Draft and edit multiple element comments before sending them
• Mark the preview as Approved or request Changes
• Approve a specific required slot when they use a slot-specific review link
• See submitted review items, item status, and developer replies when they reopen the review link

Submissions are stored in prev and appear in the Feedback Inbox under Dashboard → Feedback. Developers using the CLI can also list feedback for previews created with their API key.

End-to-End Review Flow

Reviewer Flow

The reviewer does not need to install anything. They open the preview, click the light-blue review flag on the right edge of the screen, and work through the running app while the full-height sidebar stays available.

• Enter a reviewer name and optionally an email address without creating an account
• Clicking a visible DOM element creates a draft review item for that exact element
• Clicking an already pinned element focuses the existing draft or item instead of creating a duplicate
• Each draft has its own editable comment field in the sidebar
• Reviewers can mark multiple elements, edit comments, and remove drafts before sending
• Send submits all pending drafts as separate review items
• Reviewer replies can be added to already submitted review-item threads
• Request changes records a blocking review decision for the current round
• Approve approves the current review or the approval slot attached to a magic review link

Submitted items are locked in the reviewer sidebar so the original review state stays stable. Follow-up discussion happens as replies on the specific item thread. If a network request fails, the unsent draft remains editable so the reviewer can retry without recreating the whole review pass.

Developer Flow

Developers receive the same review data wherever they work. The Dashboard inbox shows every pinned item with reviewer identity, message, page context, item status, and replies. The CLI and local mini-dashboard expose the same item list for developers who prefer terminal or local tooling.

• Open the Feedback Inbox to see review status, unread items, review rounds, and approval history
• Open the signed review overlay to inspect pins inside the live preview UI
• Mark individual review items as done or reopen them if more work is needed
• Add a developer reply to a specific review item thread
• Use prev feedback or prev ui to review the same feedback without opening the full Dashboard

Enabling the Widget

Pass the --feedback flag when creating a preview environment:

prev create . --feedback

This activates the widget for that specific environment. Environments deployed without --feedback do not include the widget.

Combining with a Notification Profile

On the Teams plan, you can route feedback notifications to Slack, Discord, Microsoft Teams, Google Chat, email, or a custom webhook by specifying a notification profile with --notify:

prev create . --feedback --notify acme-corp

The named profile must exist in your Dashboard under Dashboard → Notifications & Webhooks. See the Notifications & Webhooks documentation for setup instructions.

Review Status and Approvals

Feedback-enabled previews track a structured review status. New feedback previews start as pending_review. A reviewer can request changes_requested, required approvals can move the preview to approved, and unfinished reviews can become expired when the preview expires.

For reviews that need more than one sign-off, define required approval slots when creating the preview:

prev create . --feedback --approval-slots client,qa

Each slot is tracked separately. The review is approved only after every required slot has approved the current review round.

Magic Review Links

When a preview has approval slots, prev returns slot-specific review links in addition to the normal preview URL. A magic review link identifies the reviewer role for that link, so an external stakeholder can approve the correct slot without creating an account.

The normal preview URL still works for browsing and general feedback. Use magic review links when a specific person or role must be tied to a required approval.

CI/CD Integration

Add --feedback to your CI/CD workflow to automatically enable feedback collection on every pull request preview:

name: Deploy Preview

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  preview:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install prev
        run: curl -fsSL https://prev.sh/install.sh | sh

      - name: Deploy with feedback
        run: prev create . --feedback --subdomain pr-${{ github.event.number }}
        env:
          PREV_API_KEY: ${{ secrets.PREV_API_KEY }}

Combined with a notification profile, your team gets a Slack or Discord ping every time a reviewer submits feedback on a PR preview.

The Feedback Inbox

All submitted feedback is collected in the Dashboard under Dashboard → Feedback. The inbox provides:

Filtering

• All: Every feedback submission
• Unread: Submissions you have not yet opened
• Approved: Submissions where the reviewer clicked Approve
• Changes Requested: Submissions where the reviewer requested changes

You can also filter by notification profile to see only feedback for environments linked to a specific project.

Reading Feedback

Click any feedback item to expand it and read the full message. Expanding an item automatically marks it as read. You can also use the Mark all as read button to clear the unread count at once.

For pinned element feedback, each marking is a separate review item. Developers can mark an item as done, reopen it, and add a developer reply to the item thread. Reviewers see those item statuses and replies when they reopen the same review link, and can answer inside the same item thread.

If a feedback item is no longer needed, users with feedback management access can delete it from the expanded inbox item. Deleting feedback permanently removes that submission.

Unread Badge

The Dashboard sidebar shows a live unread count badge next to the Feedback navigation item whenever there are unread submissions. The count updates as you read items.

Pagination

The inbox is paginated with 20 items per page. Use the Previous / Next controls to navigate through older submissions.

Review Summary and Decision History

Each feedback-enabled preview has a review summary that shows the current status, current review round, open change requests, received approvals, missing approvals, latest comments, reviewers, and the build reference when available.

Approvals and change requests are also stored in a decision history. This keeps a durable record of who approved or requested changes, when it happened, which page they were on, which approval slot they used, and what the final review status was at that point.

Pinned Feedback and Review Overlay

Reviewers open a review flag on the right edge of the running preview. A full-height review sidebar slides out with a review-item list plus Send, Request changes, and Approve actions. While the sidebar is open, reviewers can click visible DOM elements directly on the page. Each selected element becomes its own editable draft in the sidebar. If the same element is clicked again, Prev focuses the existing draft or item instead of creating a duplicate. Reviewers can add comments to multiple elements, remove drafts before sending, and submit the batch when they are done.

After submission, each draft becomes a locked review item with its own pin, status, page context, and thread. Prev stores the selector, element text, bounding box, click point, viewport, browser, and page URL with each pinned comment. Open and resolved item status is available in the Dashboard, CLI, mini-dashboard, and reviewer sidebar.

Developers can open the signed review overlay link from the CLI output or Dashboard Feedback Inbox. The same preview loads with pins for the current review round, so developers can inspect reviewer comments in the live UI context instead of matching text feedback back to a page manually. The overlay also shows whether a pinned item is still open or already resolved.

Screenshot and element-crop capture are planned next. The current implementation stores structured element context and live overlay pins without storing image payloads.

Review Item Lifecycle

Each pinned element comment becomes an individual review item. Review items are open by default and can be marked resolved by a developer after the requested change has been handled. Resolved items remain in the review history, but they no longer count as open change requests in the current review summary.

Each item also has its own thread. Developers can add replies to explain what changed or why an item was reopened. Reviewers can see these replies and the current item status when they return to the review link, then answer inside the same thread. This keeps discussion tied to the exact DOM element instead of spreading follow-up across separate messages.

Review Rounds and In-Place Updates

If a feedback-enabled preview is updated with prev create --to <subdomain> ., a successful deploy starts the next review round on the same URL. The preview goes back to pending_review, new feedback and approvals are attached to the new round, and approvals from earlier rounds no longer count for the current round.

Previous change requests remain visible as previous changes, so reviewers and developers can see what was already raised without blocking the new approval state. Failed in-place updates do not advance the review round.

Developer Access

Developers who create review environments from the CLI can read feedback without opening the full Dashboard. The CLI uses the configured API key, so it shows feedback for review environments visible to that key.

prev feedback
prev feedback my-preview
prev feedback --approved
prev feedback --unread

For a local browser view, run prev ui and open an environment detail page. The mini-dashboard includes a Feedback tab next to Logs and Stats, including the review summary, decision history, review-item status, and item replies.

What Gets Captured

Each feedback submission stores the following data:

Widget Behavior

The feedback widget is injected as a small, non-intrusive floating button. It does not affect the layout or styling of the preview. Key behaviors:

• The widget is loaded via a <script> tag injected by the prev nginx sidecar
• It communicates directly with the prev Dashboard API over HTTPS
• Each environment gets a unique, signed token — feedback cannot be spoofed or submitted to the wrong environment
• Pinned feedback uses a signed developer overlay link to show comment pins in the running preview
• Reviewer draft comments stay editable in the sidebar until they are sent; submitted items are locked
• Developer replies, reviewer replies, and resolved/open status are visible when the reviewer opens the review link again
• The widget works in any modern browser and uses local storage only to remember the reviewer's name and optional email for that preview
• Submissions are accepted only from the environment's own domain, preventing cross-origin abuse

Planned Review Additions

The current review flow covers multi-element feedback, reviewer identity, approvals, item status, developer and reviewer replies, and live overlay pins. The next review-specific additions are:

• Reviewer notifications: notify reviewers when a developer replies to an item or marks an item resolved
• Return-to-review state: use email, digest, or magic-link based return flows so anonymous reviewers can get back to their open items
• Screenshot or element crop capture: store visual snapshots for cases where live DOM context may change before the item is resolved

Plan Availability

Related

• Notifications & Webhooks — Route feedback to Slack, Discord, Microsoft Teams, Google Chat, email, or a custom webhook
• In-Place Updates — Push new code to the same preview URL and start the next review round
• CLI Commands — Full reference for --feedback, --notify, prev feedback, and prev ui