Bulk destructive actions must list the objects they will affect

What it is

A count and a scope phrase tell you scale, not names. Irreversible or high-cost bulk actions — delete, archive, revoke access — still need an object listing for bulk destruction: a scannable set of identifiers, not merely “Delete 40 items?” Scale and wording can both be correct while a just-mis-checked row sits in the set. This constraint does not cover how the selected count is shown. It covers whether objects can be claimed by name before destruction.

Why it happens

Destructive bulk compresses many objects into one confirmation. A dialog is good at catching a slip on the button, and bad at catching a stranger in the set — that takes recognition, and recognition takes names. Almost no one can audit the number 40; they can only accept or abort the whole pile. Listing identifiers moves the audit from abstract scale back to concrete objects: the contract that should not go, the colleague who should keep access. The list has to be the objects’ identifying fields, not internal ids or “Item 1, Item 2.” When the list is long it must remain scrollable, and it should let people drop individual members before confirm, or it collapses back into an unauditable scale.

Studying it

On a selection known to contain one record that must not be deleted, compare three confirms: count only, count plus scope wording, and a scrollable list of identifiers. Dependent variables: rate at which the stray record is found and removed, time to confirm, actual mistaken deletions. Independent variables: set size, whether identifiers are truncated, whether individual objects can be dropped in the confirm. As the set grows, discovery under count-only should approach zero; under a list it should fall with scannability, not drop off a cliff.

Where it stops holding

Reversible, low-cost actions (mark forty mails read) do not need an object list; a count is enough. If identifiers cannot be loaded before confirm, the list arrives empty or as internal ids, which is more dangerous than no list, because an empty roster is read as “nothing to audit.” When permissions hide a name the user is not allowed to see, the list cannot point; refuse to include invisible objects in the bulk set rather than printing “restricted item.” True whole-store destruction (empty trash at tens of thousands) is past scannability and needs a typed confirmation phrase — a different high-cost channel, not a pretend listing.

Applying it

• In confirms for delete, permanent remove, or bulk permission change, list identifying fields; show a few by default and let the rest scroll.
• Allow dropping individual objects in the confirm and recompute the set that will run; do not force all-or-nothing.
• If an identifier is truncated past recognition, that list row has failed — widen it or offer the full string.
• How to check: seed a record that must not be processed and see whether the confirm stage can surface it. If it cannot, do not ship that bulk entry.

Related

• Within the group: E4.05.1 Too many inline actions crowd out the content they act on · E4.05.2 Bulk actions must show how many items are selected and the scope they will affect
• Adjacent: E6.05 Confirmation dialogs · E1.03 Destructive action buttons
• Search terms: bulk delete · destructive confirmation · affected items