Bulk Actions
Selecting many records and doing one thing to all of them — and designing what happens when it works for most but not all.
UI ComponentsBulk actions are three problems wearing one label: selecting the right records, understanding what is about to happen, and handling partial failure. The first two are usually designed. The third almost never is, and it is the one that costs data. “Delete 200 items” where 197 succeed and 3 fail must say which three and why — a toast saying “Done” is a lie with consequences.
Selection has its own trap: the difference between “all 50 on this page” and “all 4,312 matching the filter”. Most implementations blur the two, so a user who selected a page and clicked delete removes far more than they meant to. Say which set is selected, in words, and make choosing the larger set a separate deliberate click.
Undo beats confirm
A confirmation dialog is read once and then dismissed reflexively forever. For anything reversible, an undo window in a toast protects people better. Keep the dialog for the genuinely irreversible, and name what is about to happen in it.
In practice
A CRM let users select all contacts matching a filter and apply a tag. The API capped at 1,000 records per call. The UI reported success after the first call. Users found roughly a third of their 3,000 contacts tagged and assumed the filter was wrong. Paginating the calls and reporting real counts — with a downloadable list of failures — closed a bug that had been reported as “filters are broken” for months.
Where teams get it wrong
- Reporting success when part of the batch failed.
- Blurring “selected on this page” with “all matching the filter”.
- No undo for reversible bulk operations, only a confirm nobody reads.
- No progress indication on long batches, so the page looks frozen.
- Selection lost when the user paginates or refines a filter mid-task.
Learn more
You may ask
Frequently Asked Questions
How should bulk actions handle partial failure?
Report the real counts, list which records failed and why, and let the user retry just those. An exportable list of failures is the difference between a recoverable afternoon and silent data drift.
Should bulk actions ask for confirmation?
For irreversible ones, yes, naming what will happen and to how many records. For reversible ones, an undo window works better — confirmation dialogs stop being read after the second time.
Related terms
All terms- Data TableA grid of rows and columns for scanning, comparing and acting on records — the screen most B2B users spend their day inside.
- CheckboxA control for independent on/off choices, any number of which can be selected at once — including none.
- Toast NotificationA brief message that appears over the interface to confirm an action or report a problem, then disappears on its own.
- Error StateWhat an interface shows when something failed — which system failed, whether the user's work survived, and what they can do next.
Defined by Mara Last reviewed .
Let's talk about your product.
Happy to look at what you're building and say where design would move the needle.
Contact Us