Bulk action UX: what happens when only half the job works?

An operations manager selects 240 customer records and clicks “Assign owner.” The screen spins, then says “Something went wrong.” Some records have changed. Others haven’t. Clicking again might fix the problem, repeat the work, or make the mess harder to untangle.

This is an illustrative scenario, but it makes a useful test for an enterprise UX agency. A polished dashboard can hide this problem until someone starts using it. A working design needs to explain what the action affected, what happened to each record, and what the operator can safely do next.

Give a prospective partner one bulk operation from your internal tool. Ask them to follow it through a partial failure. Their questions will tell you more than another screen of attractive charts.

What exactly has the user selected?

“Select all” can mean every visible row, every row on the current page, or every result matching a filter. Those are different commitments. Make the scope visible beside the action: “25 selected on this page” or “240 matching records selected.”

The Carbon Design System’s data-table guidance describes a familiar starting point: row checkboxes and a batch action bar that appears when the user selects items. That pattern establishes the interaction. Your product still needs to define what happens across pages, filters, and changing data.

In the example, the manager filters for accounts without an owner. Another operator assigns one of those accounts before the job starts. Decide with engineering whether the job uses a saved selection or reevaluates the filter. Show the resulting scope before committing the change. An apparently minor selection rule can otherwise change who receives work.

Preserve the selection when practical, but don’t silently carry hidden records into a new filter. If the scope changes, explain it where the user is making the decision.

Which records can the action affect?

A selection can include records the operator may view but may not change. Other records may be locked, archived, or already assigned. The product must distinguish those conditions from a service failure.

For this example, suppose a preflight check finds 20 records outside the operator’s permissions. The confirmation could say: “Assign 220 eligible accounts to Morgan. 20 selected accounts cannot be changed with your access.” Offer a way to inspect the exclusions without exposing information the user isn’t allowed to see.

That check does not reserve the world. Permissions and record states may change again before execution. The result view still needs to account for every selected record, including anything that became ineligible while the job ran.

Some operations must succeed together or fail together. Others can finish record by record. The design team should confirm which behavior the system supports before drawing a progress screen. A friendly interface cannot promise a transaction the backend does not provide.

What should a partial result look like?

Return to the 240 selected records. The following numbers are invented for the exercise and account for the entire selection.

The most consequential row is the last one. A lost response does not prove the operation failed. Relabeling those records “failed” and inviting a retry creates another decision on top of incomplete information.

Let the operator leave the page and return to the same job. Show when the status was last checked. If the system needs support to reconcile an unknown result, preserve a job reference and the affected record identifiers in the authorized support view.

The payoff is an intelligible receipt: 201 completed, 36 excluded or rejected for known reasons, and 3 still unresolved. “Finished” would erase information the operator needs.

When is retry safe?

Retry should target an explicit subset. “Retry 7 locked records” is easier to judge than “Try again,” especially when 201 changes already succeeded.

Before offering it, establish whether the operation can run twice without duplicating an effect. Assigning an owner, sending a notification, and issuing a payment have different consequences. Engineering owns the mechanism; the interface must represent its actual guarantees.

If a record changed after the first attempt, show the new state before asking the operator to approve another change. If the result is unknown, check the original operation first. Do not turn the retry button into an invitation to guess.

Undo needs the same precision. Reversing an assignment may be possible while recalling a notification is not. State which effects a reversal covers and which remain.

How can this become an agency evaluation exercise?

Use a small, sanitized example in a mutually agreed working session. Include an operator, someone responsible for permissions, and an engineer who knows the job system. Ask the agency to produce a selection rule, a result view, and the recovery path for one changed record.

Then introduce a complication: the operator closes the browser before completion. Can another authorized colleague find the job and explain the remaining work? Test the answer with a keyboard and a screen reader as well as a mouse. Status cannot depend on color alone.

The internal-tool agency brief covers the broader selection process. This exercise gives that process something concrete to inspect. The useful deliverable is a flow in which an operator can account for all 240 records and continue without repeating completed work. If the proposal cannot explain the last 3, the design is still unfinished.