Preventing mistakes in bulk-action interfaces

Define the selected set first

A selection may refer to a fixed set of record identities or to a query that matches records. A fixed set is easier to inspect; a query can change as new data arrives. Specify which point in time determines the set and whether newly matching records are included. The business owner should approve this behavior rather than leaving it implicit in a checkbox.

In a hypothetical list with twenty rows on a page and several hundred matching results, the first select-all action can explicitly select the page. A separate action can extend selection to all matching results. These numbers are illustrative. Actual counts must come from the system, not from the number of rows the browser happened to load.

Keep selection mode visible

The Carbon data-table guidance presents batch actions as a distinct mode after items are selected. That is a useful reference for making the mode visible, but the component does not decide a project’s cross-page scope or server authorization. Keep the count, cancellation and available actions easy to locate while the selection is active.

Specify filtering, sorting and paging separately. Sorting should normally preserve selected identities. Retaining a selection across pages needs visible confirmation. A filter change may clear selection or require confirmation, but it must not silently submit records that are now hidden. Let users inspect the selected set rather than relying only on a total.

Confirm consequences rather than displaying a generic warning

• Action: identify the field or business state that will change.
• Scope: show a record count, filter definition or inspectable set of objects.
• Exceptions: identify unavailable permissions, incompatible states or records already handled.
• Consequences: explain actual undo capability, notifications and follow-on tasks.

“Are you sure?” does little to help someone check scope. High-impact actions need a recognizable summary. Repeated dialogs may be unnecessary for low-risk actions that can genuinely be reversed. Undo must correspond to implemented business behavior; drawing an undo link does not make an operation recoverable.

Report partial success at the item level

When some records succeed and others fail, separate those outcomes and preserve the failed identities, reasons and available next actions. Retrying failed items is different from running the entire batch again. Users should not have to rebuild the selection just to recover. A timeout may mean the result was not received, so provide a way to query the task before encouraging another operation.

The server still needs to validate current permissions and state for each item. An enabled control represents only what was known before submission. Another person may change a record in the meantime. The backend must accept, reject or report a conflict according to the agreed rule. Review interface clarity and write correctness together, while recording them as separate acceptance results.

Exercise the paths that can change meaning

1. Select the current page and move to another page. Compare the scope and count with the specification.
2. Change a filter after selecting records. Verify that the former set is cleared or explicitly retained.
3. Change one record’s permission or state before submission and inspect the partial outcome.
4. Refresh while processing continues. Check that the result can be found again.
5. Retry only failed items and confirm that successful records are not processed again.

If the system can act only on currently loaded rows, call it a current-page action. A clear limited capability is safer to understand than an ambiguous “all” command. Cross-page processing can be added when the business needs it, but a visual cleanup should never silently expand the authority or reach of a bulk action.

Review bulk actions with examples of selection across pages, partial success and refreshed records. Capture the feedback rules in the prototype handoff checklist. For an existing list, also check the operations that a redesign must preserve. A brief for UI design (Chinese) needs the actual bulk actions and their outcomes, not just a preferred checkbox appearance.