How Do You Design Bulk Actions in a SaaS App?

How do you design bulk actions in a SaaS app?

Treat a bulk action as five separate design problems rather than one button. Selecting the items, showing what is selected, confirming the consequence, running the job, and recovering when part of it fails. Most products design the first and the last two badly, and users learn to avoid the feature.

Bulk actions are where a product either feels powerful or feels dangerous. The same interface that lets an admin fix 400 records in a minute lets them destroy 400 records in a minute.

This is the framework we use when we design or review one, with the specific rules for each stage.

What are the five stages of a bulk action?

Select, see, confirm, run, recover. Select is how items get chosen. See is how the current selection stays visible. Confirm is the moment of consequence. Run is what happens while the work executes. Recover is what happens when it goes wrong, which it will.

Write those five words down before designing anything. Teams that skip straight to the toolbar end up with an interface that can select but cannot report, or one that runs but cannot undo.

Each stage has a different failure mode, and each needs its own acceptance criteria in the ticket. That is the whole value of splitting them.

How should selection work?

Predictably, and with an obvious escape. A checkbox per row, a select-all in the header that selects only the current page, and a separate explicit action if the user wants to select every match across all pages. Conflating those two is the single most common bug in this pattern.

Support the conventions people already have: click to select one, shift-click to extend a range, and the Escape key to clear. These are learned behaviours, so matching them is free usability.

Selection should also survive filtering sensibly, or clear loudly. Silently keeping 300 hidden items selected after the filter changes is how a user deletes records they cannot see. Our notes on filtering and search UX cover how the two interact.

How do you show what is selected?

With a count, in words, wherever the action lives. "48 of 1,240 selected" tells the user exactly what is about to happen. A row of highlighted rows does not, especially once the list scrolls and the selected items are off screen.

Put the count next to the action, not in a corner. The number needs to be in the same glance as the button, because that is the moment the decision gets made.

Distinguish "48 selected on this page" from "all 1,240 matching items selected" in the copy itself. If the interface can do both, the label must say which one is active. Our guide to data table design covers the surrounding table patterns.

When does an action need a confirmation dialog?

Rarely, and the bar is high. Nielsen Norman Group's guidance, published in February 2018 and last reviewed in August 2026, says confirmation dialogs belong before actions with serious consequences, such as destroying users' work or costing large amounts of money, and particularly before actions that cannot be undone.

The same article warns about overuse directly: if you warn people too much, they stop paying attention. A product that confirms everything has trained its users to click through confirmations without reading them, which removes the protection exactly when it matters.

The better default, in its words, is to do your best to offer undo. A reversible bulk action with a clear undo needs no dialog at all. Our piece on undoing destructive actions goes into how to build that.

What should the confirm dialog say?

The specific consequence, and buttons that name the outcome. Nielsen Norman Group is explicit that instead of asking whether the user is sure, a dialog should explain what the action is in user-centric terms, and that response options should summarise what will happen.

Its own example is file deletion, where the buttons should read Delete file and Keep file rather than Yes and No. Apply that to bulk work and you get "Delete 48 invoices" against "Keep them".

Include the count and the object type in the heading, never just a generic warning. The number is the part a rushing admin actually reads, and it is the part that catches the accidental select-all.

How do you handle a long-running bulk job?

Stop blocking the interface and start reporting progress. Anything that may take more than a few seconds should run in the background with a visible status, so the user can keep working and come back to a result rather than watching a spinner.

Say what is happening in text, not just with a bar: how many are done, how many remain, and whether it can be cancelled. If it cannot be cancelled, say so before it starts rather than greying out a button mid-run.

Keep the result somewhere durable. A toast that disappears after four seconds is not a report, and the person who triggered a 20 minute job is often not at their desk when it finishes.

What happens when half the items fail?

You show both halves, honestly, with a way to retry only the failures. Partial success is the normal outcome of bulk work, and it is the case most products do not design at all. The worst version reports success because the job finished.

Give the failures a reason each, grouped by cause, and make them downloadable or copyable. An admin who can see that 12 records failed because of a permission issue can fix it. An admin who sees "some items could not be updated" has to guess.

Then let them act on just those items. A retry that reruns all 400 to fix 12 is a new risk, not a fix.

How do you make bulk actions accessible?

Announce state changes and label every control. WCAG 2.2, a W3C Recommendation since 12 December 2024, includes success criterion 4.1.3 Status Messages at Level AA, which requires that messages about the status of the application or the result of a user action can be programmatically determined through role or properties.

In practice that means the selection count and the job result have to reach assistive technology, not just appear visually. A user who cannot see the count cannot safely use the feature.

Icon-only toolbars are the other trap, and it is widespread. WebAIM's February 2026 Million report found empty buttons on 30.6 percent of home pages and missing form input labels on 51 percent. A bulk action bar made of unlabelled icons is that same defect, in the most consequential place in your product.

What would we fix first in an existing product?

The selection count and the partial failure report, in that order. Those two changes remove most of the fear users feel about the feature and most of the support tickets it generates, and neither of them requires touching the underlying job or the database work behind it.

After that, audit which confirmations actually protect something. Removing three pointless dialogs makes the one real dialog meaningful again, which is the point Nielsen Norman Group has been making since 2018.

If you want a review of a bulk workflow before you build it, we are happy to walk through it. You can see how we approach product and interface work at phoenix.studio.