Interface Lab
Login
Back to knowledge
Interaction Responsive Motion

Batch Action Preview and Diff

Batch actions need selection scope, action object, affected count, failure branches, and undo/audit paths; dangerous bulk changes must show a diff before submission.

bulk-actionstablesdiffconfirmationadmin

Design Principle

Batch actions increase efficiency and amplify mistakes. The interface must make current selection, action scope, invalid items, dangerous consequences, async progress, and recovery path explicit.

Large Theory

A batch action is not just a few buttons added to a table. It changes the user's mental model from acting on one object to acting on a temporary collection. That collection may come from the current page, current filter, all results, cross-page selection, or an imported list. If scope and impact are unclear, delete, permission change, archive, export, invite, and tag-update actions can cause broad damage.

Small Points

  1. Selection scope must be readable: 12 selected items, 50 items on this page, and all 3,420 filtered results are different things.
  2. Once batch mode is active, row-level single actions should be de-emphasized or disabled so users are not in single-item and multi-item modes at once.
  3. Preview the diff before submission: which fields change, from what to what, which items will fail or be skipped, and whether people will be notified.
  4. Dangerous batch actions need secondary confirmation, reason field, permission check, and audit record. Reversible actions should prefer undo.
  5. Long tasks show queued, running, partial success, failed, and completed states, with background continuation and result download paths.
  6. Mobile batch selection should not depend on hover checkboxes; it needs a clear selection bar, bottom action sheet, or list-selection mode.

Design Judgment

A batch operation is safe when users can accurately restate impact scope, risk, failed items, and recovery path before final submission. If the button only says Delete selected, the design is incomplete.

Implementation Notes

Create a batch action contract: selectionSource, selectionCount, selectionScope, eligibleCount, ineligibleItems, actionVerb, targetField, beforeValue, afterValue, riskLevel, requiresReason, notifyUsers, asyncJobId, undoWindow, and auditId. The frontend flow is select -> batch bar -> preview diff -> confirm -> progress -> result summary. Failure summaries include downloadable details and retry entry.

Counterexamples/Risks

Select all only selects the current page but sounds like all results, bulk delete has no preview, invalid items appear only after failure, the page clears immediately with no progress, partial success has no details, a toast replaces the result summary, and mobile users cannot cancel selection.

Case Study

Carbon Data Table batch action guidance says selecting rows reveals a batch action bar at the top of the table and disables row actions while batch mode is active. Carbon style guidance documents batch action bar density. GitHub audit log export documentation shows export can be scoped to filtered results. Together these patterns show that batch actions must bind selection scope, current mode, and result evidence together.

Source Links

Carbon Data Table usage: https://carbondesignsystem.com/components/data-table/usage/ Carbon Data Table style: https://carbondesignsystem.com/components/data-table/style/ Carbon Common Actions: https://carbondesignsystem.com/patterns/common-actions/ GitHub audit log export: https://docs.github.com/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/reviewing-the-audit-log-for-your-organization GOV.UK notification banner: https://design-system.service.gov.uk/components/notification-banner/

Agent Directive

Before generating batch actions, define selectionScope, eligible/ineligible items, preview diff, dangerous confirmation, async progress, partial success, and undo/audit paths; do not add only a bulk button.