The Hidden Complexity of Bulk Actions

It Starts Simple

The feature request is always the same: "Users need to be able to update multiple records at once." On a whiteboard, it's three steps — select, action, confirm. Ship it.

Then you talk to the engineers. And you realize that "bulk update 500 records" is not one operation. It's 500 operations, potentially distributed across services, with no guarantee they all succeed together.

The Partial Failure Problem

What happens when 498 records update successfully and 2 fail? This is the question that separates a real bulk action design from a prototype.

Your options: rollback everything (transactional), commit what succeeded and report failures (partial), or block the operation if any record is invalid (pre-validation). Each has tradeoffs, and the right answer depends on the domain.

For content operations, we chose pre-validation — show which records are ineligible before committing. This feels slower but is far less disorienting than a post-hoc error report.

Trust at Scale

When an operator selects 300 records and hits "Publish," they need to trust the confirmation step. That means the confirmation has to be specific: not just "Are you sure?" but "This will publish 298 videos to the US store and 2 to the UK store. 0 records have errors."

The numbers build trust. Vague confirmations erode it.

What I'd Do Differently

I'd invest earlier in the empty-selection and mixed-state designs — what happens when selected records span incompatible states. We got there, but it took too many iterations.

Bulk action design is really state machine design. Think of it that way from the start.