Define the selection clearly
Distinguish the visible page from every record matching a filter. If selecting all means more than the rows currently displayed, show the scope explicitly before the action runs.
Keep the selection understandable as filters or pagination change. Decide whether newly arriving records are included or whether the operation acts on a fixed selection. A stable set is easier to explain when the underlying list changes frequently.
Check eligibility before acting
Some selected records may no longer be in a valid state. Show a useful preview when the consequence warrants one, and validate eligibility again when applying the operation.
Decide whether one invalid record should stop the entire batch or whether eligible records can proceed. Neither behavior is universally correct. The workflow should determine the choice, and the confirmation should explain it before the user commits.
Report results at the same level
Summarize completed, skipped, and failed items separately. Provide a way to inspect the affected records and the reason for each failure. Do not require someone to infer the outcome by comparing the list before and after the operation.
Plan retry and recovery for partial completion. A repeat should not accidentally reapply a destructive or externally visible effect to items already processed. Where an undo is supported, explain its boundary and any effects it cannot reverse.
Test with records that change during the operation and with a browser that disconnects before completion. The person should be able to return to a durable result rather than losing the only explanation of what happened.
A practical example.
An administrator selects twenty inactive accounts to archive. Before confirmation, the application should state whether the action affects those twenty records or every record matching the current search. That distinction becomes critical when pagination hides most matches.
If three records cannot be archived because they own active work, report the seventeen completed changes and identify the remaining three. A blanket “failed” message encourages unnecessary retries; a blanket “success” hides unfinished work. Decide whether the operation needs a preview, whether it can be cancelled, and how changes are recorded. Test the action with records that change after selection so the system has a defined response to stale assumptions.
Put it into practice.
- Make the scope of selection explicit across pages and filters.
- Preview consequential changes and explain whether they can be reversed.
- Report per-record exceptions and the final totals after partial completion.