Next.js Bulk Actions: Safe Selection, Preview & Partial Recovery

Distinguish selected rows from every matching record

A table checkbox can mean the visible page, an explicit set across pages, or every record matching a filter. Those scopes must be visible before an action changes data. A count alone does not explain whether newly arriving records will also be included.

Make select-page and select-all-matching separate actions. Reset or clearly preserve selection when filters change. Derive the server selection from trusted tenant context rather than accepting an arbitrary client query.

Preview the exact operation users will confirm

Validate the action, target fields, selection size, and current eligibility before presenting counts. Show how many records will change, how many are ineligible, and which consequences matter, such as notifications or irreversible transitions.

Store a manifest with action parameters, tenant, requester, selected IDs, relevant revisions, creation time, and expiry. Confirmation should reference that manifest. A changed action or scope requires a fresh preview, and an expired preview should not execute silently.

For very large selections, build the manifest asynchronously and expose progress. Use a consistent snapshot or another deliberate selection boundary so records added during scanning do not unpredictably enter the operation.

Check permission for every target at execution time

A user who can edit one row may not edit every selected row. Resolve identity and tenant on the server, apply action-specific authorization, and recheck eligibility before each mutation. A valid preview does not preserve permission after membership or policy changes.

Choose whether ineligible records reject the entire operation or produce per-item skips. State that policy in the preview. Do not expose private record names in failure reports merely because a submitted ID exists.

Define what happens when records change after preview

Version-sensitive operations should compare the manifest revision with current state inside the write. Skip or report a conflict when the record changed. Actions expressed as domain commands may instead validate their own current-state predicate, such as moving only pending requests to approved.

A broad update that overwrites every field can erase intervening work. Limit writable fields and validate the complete domain invariant. Our concurrent-edit guide explains atomic revision checks.

Run large operations as resumable work

Return an operation ID instead of holding one browser request open for thousands of mutations. Track accepted, queued, running, cancel_requested, completed, partially_failed, and failed states. Store per-item outcomes or durable batch checkpoints appropriate to the action.

operation: action + manifest + requester + tenant
item: target ID + expected revision + operation key
outcome: changed | skipped | conflict | failed

commit mutation + item result + outbox event together;
acknowledge work only after that transaction commits.

Bound concurrency and transaction size so bulk work does not exhaust capacity for interactive users. The background-work guide covers leases, backpressure, and worker recovery.

Prevent retries from repeating completed effects

Use a stable operation key for each action and target. A worker can crash after commit but before acknowledgment, so replay must return the prior outcome or verify the current operation state. Keep notification and external-provider work behind a durable event boundary.

Retry transient failures with bounded backoff. Conflicts, denied permissions, and invalid state transitions require a different resolution path. Do not label every failed item retryable or restart the entire selection after partial success.

Separate stopping work from reversing completed work

Cancellation should stop new claims and let in-flight transactions reach known outcomes. Show the already committed count. A canceled operation may still have successful items, and closing the browser should not be interpreted as cancellation.

Undo needs an explicit domain design. Record before-values or reversible commands where appropriate, verify that later edits do not conflict, and define an expiry window. External notifications, shipments, and other irreversible actions may require compensation rather than reversal.

Report outcomes in a way users can act on

Show processed, changed, skipped, conflicted, and failed counts with clear definitions. Provide a protected results view and a targeted retry action for eligible failures. Reconcile terminal counts with the manifest size so omitted items cannot disappear behind a success banner.

Use accessible checkbox labels, a mixed state for partially selected pages, and keyboard-operable bulk controls. Announce progress summaries without reading every row change. Keep the operation accessible after navigation or reload, with a clear link from the initiating screen.

Test scope boundaries and partial completion

Exercise filter changes after selection, rows added during preview, revoked permissions, record deletion, concurrent edits, duplicate confirmation, and worker crashes after commit. Verify that the final target set matches the documented selection rule.

Cancel mid-batch, replay completion events, and retry only failed items. Measure queue age, mutation throughput, conflicts, authorization skips, duplicate suppression, and count reconciliation. Retain safe audit evidence of actor, action, manifest, and outcomes using our audit logging guide.

Next.js bulk action checklist