Bulk Actions

Users need to perform the same operation across many records. Repeating it row by row is slow and error-prone, but acting on many records at once raises new questions: what exactly is selected, what happens to records the user can't act on, and how do they recover when part of the batch fails?

1. 01

   Table at rest

   Search, filters and view controls are visible.

2. 02

   Select first row

   Checkbox, Shift-click for ranges, or Space on a focused row.

3. 03

   Selection mode

   Toolbar swaps to count, actions and Clear.

4. 04

   Choose action

   Ineligible records are counted before anything runs.

5. 05

   Confirm if destructive

   Dialog states the exact count and consequence.

6. 06

   Processing

   Rows lock; progress is shown for long batches.

7. Result

   • Success
   • Partial failure
   • Failure

• Default

  No selection. Table toolbar shows search, filters and view options.

• Row hover

  Desktop only. Row tints and the checkbox becomes more prominent to signal selectability.

• Partially selected

  Header checkbox shows the indeterminate state; toolbar shows “3 selected”.

• All visible selected

  Header checkbox checked. Offer to extend the selection to every matching record.

• Action unavailable

  Action shown but disabled, with a tooltip explaining why — e.g. “Paid invoices can’t be approved.”

• Processing

  Selected rows are locked, the toolbar shows progress, and other bulk actions are disabled.

• Success

  Toast confirms the count, selection clears and Undo is offered when reversible.

• Partial failure

  Successful records update; failed records stay selected with an inline reason per row.

• Failure

  Nothing changed. Selection is preserved so the user can retry without reselecting.

1. EC-01

   Selection + filters

   The user selects 12 records, then changes the active filter so some selected records disappear from view.

   Recommendation

   Clear the selection when the result set changes and say so: “Selection cleared because the filter changed.” Acting on records the user can no longer see is the more dangerous failure.

2. EC-02

   Selection across pages

   The user selects rows on page 1, moves to page 2 and selects more.

   Recommendation

   Persist the selection across pages and always show the total count. Provide a “Show selected” view so users can audit records they can’t currently see.

3. EC-03

   Select all matching

   The user checks the header checkbox on a list of 1,284 filtered results with 50 visible.

   Recommendation

   Select the 50 visible rows only, then show an inline banner: “50 selected. Select all 1,284 matching invoices?” Never silently select records the user hasn’t seen.

4. EC-04

   Mixed eligibility

   20 rows are selected but only 15 can be approved; 5 are already paid.

   Recommendation

   Keep the action enabled and state the split before running: “Approve 15 invoices? 5 are already paid and will be skipped.” Disabling the button entirely leaves users guessing which rows are the problem.

5. EC-05

   Mixed permissions

   The user can edit some selected records but not others.

   Recommendation

   Treat it like eligibility for reversible actions — apply to permitted records and report the rest. For destructive actions, block and list the records the user lacks permission for.

6. EC-06

   Partial failure

   18 operations succeed and 2 fail due to a validation rule.

   Recommendation

   Report both numbers: “18 invoices approved. 2 couldn’t be approved.” Keep the 2 failed rows selected with an inline reason, so the next action is obvious.

7. EC-07

   Record changed by someone else

   Between selection and confirmation, a teammate approves one of the selected invoices.

   Recommendation

   Re-validate on the server at execution time. Report it as skipped, not failed: “1 invoice was already approved by Dana.”

8. EC-08

   Very large batches

   The user exports or updates 40,000 records.

   Recommendation

   Run the job in the background, return control immediately and notify on completion. Do not hold the user on a spinner for an operation measured in minutes.

• Selection count

  Avoid

  “Items selected”

  Prefer

  “3 invoices selected”

• Destructive confirmation

  Avoid

  “Are you sure?”

  Prefer

  “Delete 24 customers? This can’t be undone.”

• Partial failure

  Avoid

  “Something went wrong.”

  Prefer

  “18 invoices approved. 2 couldn’t be approved.”

• Eligibility before running

  Prefer

  “Approve 15 invoices? 5 are already paid and will be skipped.”

• Selection reset

  Avoid

  “Selection lost”

  Prefer

  “Selection cleared because the filter changed.”

• Undo

  Avoid

  “Action completed”

  Prefer

  “12 invoices archived. Undo”

• Selection must not rely on colour alone — the checkbox state is the source of truth, row tint is secondary.
• Every row checkbox needs an accessible name that identifies the record, e.g. “Select invoice INV-1024”.
• The header checkbox must expose the mixed state via aria-checked="mixed" when partially selected.
• Announce selection count changes through a polite live region; do not announce every individual toggle.
• When the selection toolbar replaces the table toolbar, keep keyboard focus on the row the user was on.
• Escape should clear the selection and exit selection mode on desktop.

1. 01

   Store selection as a set of stable record IDs, not row indexes or object references, so it survives sorting, pagination and refetching.

2. 02

   Model “all matching” as a query plus an exclusion list, not as an enumerated list of IDs. This keeps 40,000-record selections cheap and correct.

3. 03

   Bulk endpoints should return per-record results ({ id, status, reason }) rather than a single success boolean. The partial-failure UI depends on it.

4. 04

   Re-check eligibility and permissions server-side at execution time; the client view may be stale.

5. 05

   Make bulk operations idempotent so a retry after a timeout can’t double-apply.

Implement a production-quality bulk selection system for the existing data table.

Requirements:
- Individual row selection via a leading checkbox column.
- Header checkbox selects visible rows only, with an indeterminate state when partially selected.
- After selecting all visible rows, offer "Select all N matching" as an explicit second step.
- Shift-click selects a contiguous range.
- Store selection as a Set of stable record IDs; persist it across pagination and sorting.
- Clear the selection when filters or search change, and show a short notice explaining why.
- When at least one row is selected, replace the table toolbar with a contextual selection toolbar: selected count, primary actions, overflow menu, Clear selection.
- Before running an action, compute eligible vs. ineligible records and show the split in the confirmation.
- Confirmation dialog for destructive actions, stating the exact count and consequence.
- Processing state: lock selected rows and disable other bulk actions.
- Handle per-record results from the API: success, skipped, failed (with reason).
- On partial failure, keep failed rows selected and show the reason inline.
- Offer Undo for reversible actions.
- Keyboard: Space toggles focused row, Escape clears selection. Announce count changes via a polite live region.
- On mobile, use an explicit selection mode with a bottom action bar instead of checkboxes on every card.

Do not redesign the existing interface.
Keep interaction logic in a reusable hook, separate from presentation.

React + TypeScript reference code for this pattern — logic, hook, component and tests — is included in Statecraft Pro.

• Advanced FiltersData
• ConfirmationWorkflow
• PermissionsWorkflow
• Partial FailureWorkflow
• Activity HistoryData