Write the scope as a sentence
Use a sentence that can survive outside the table layout:
Assign 12 individually selected open requests from the West region to Morgan Lee. Ten are currently eligible; two locked requests will be skipped.
That sentence contains the action, changed value, selection rule, active filter, selected count, eligible count, and exclusions. It is more reviewable than a checkbox state plus a generic Apply button.
Carbon's current data-table guidance shows a batch-action bar after selection. Dell's table guidance defines its select-all control as all viewable rows in the current view. These are useful reference patterns, not a universal meaning for “all.” If your product selects every filtered row across pages, say that explicitly next to the control.
Separate six sets
| Set | Question it answers |
|---|---|
| Visible | Which records are rendered now? |
| Filtered | Which records match the current query? |
| Selected | Which records did this interaction include? |
| Eligible | Which selected records pass current action rules? |
| Applied | Which records actually changed? |
| Skipped or failed | Which records did not change, and why? |
These sets may overlap, but they are not interchangeable. A checkbox can express selection; it cannot prove eligibility, authorization, or a completed mutation. The server must re-evaluate those facts against the current record versions.
Review before high-impact execution
For a reversible tag change on three visible rows, a persistent action bar may be enough. For a destructive, externally visible, or cross-page change, add a review step that includes:
- the exact action and new value;
- the scope rule and active filters;
- selected, eligible, and excluded counts;
- a way to inspect selected or excluded records;
- whether new matching records can join the set before execution; and
- the recovery, retry, or escalation path.
Freeze or identify the request at confirmation. Otherwise “all matching open requests” can change between review and execution without the user knowing which population the server used.
Report outcomes without compressing them
After execution, do not show “Done” when 10 records changed and two did not. Show applied, skipped, and failed counts separately, with a path to the affected records. A skipped record is not necessarily a failure: it may have become ineligible or locked. A failure may be retryable, while an authorization denial may require escalation.
W3C status-message guidance requires status changes presented without moving focus to be programmatically determinable. Keep the visible result useful too. A user should not need to rescan hundreds of rows to infer whether an action succeeded.
Acceptance checks
- Select all says visible page, filtered result, or entire collection.
- Active filters and the current page remain discoverable after selection.
- Selection count changes are both visible and programmatically exposed.
- Ineligible records are identified before execution when possible.
- The review states the changed field and value, not merely “Apply.”
- The server rechecks record authorization, eligibility, and version.
- The result separates applied, skipped, failed, and unknown outcomes.
- Retry targets only the intended unresolved records.
- Clearing or changing filters has a defined effect on accumulated selection.
This contract remains technology-neutral. It applies whether the view is built with a plain HTML table, a data-grid library, or a mobile list, but each implementation still needs keyboard and assistive-technology testing.