Does “select all” mean 20 records or 240?

Agree on the targets before adding the checkbox

When someone asks for select all, I would first ask what they need to do in one operation. Selecting a few visible records and processing every search match are different tasks. The same feature label could mean 20 targets or 240. Leaving that decision implicit pushes it onto engineering or support later.

This example adds a Needs review marker to exhibition materials. There are 240 matching records and 20 per page. Deletion, payment and external messages are outside the case. I would restate the purpose as processing the scope a person has confirmed. The proposal records why that scope matters; the specification records when its membership persists or changes.

Check the outgoing targets after moving to another page

Reproduce the interaction with the same fictional records in both the UI and request. Select 20 on page one, move to page two and select one more. Check whether the count says 21 and whether the request contains those same 21 IDs. If selection is stored by row position, sorting can silently select different records.

Matching counts are necessary but insufficient:20 different records still produce a count of 20. Record the query, page, visible checkboxes, total selected and outgoing target set together. Independently created example records are enough to reproduce this behavior; private customer data adds nothing to this check.

Name the scope instead of hiding it behind “all”

One option is to let the header checkbox select all 240 matches. But would someone who can see only 20 notice the additional 220? Selecting just 20 while labeling the action “select all” causes the opposite misunderstanding. The text and the actual scope need to change together.

PatternFly distinguishes selecting a page from selecting across all pages and allows unsupported all-results selection to be omitted. Carbon connects selection states with actions on selected rows. For this case I would offer Select 20 on this page, followed by a separate Select all 240 results action. If the server cannot freeze that second target set, ship only page selection. These public patterns inform the distinction; the following membership rules are our example design.

240 means a fixed set, not a query run again later

All-results selection asks the server to freeze the accessible matching IDs at that moment. Show the confirmed count and capture time only after that response arrives. Disable execution while preparing the set. If preparation fails, show zero selected and a way to select again; do not display completion before the targets exist.

Removing one of 240 leaves 239. Five newly arriving records do not change that selected set. Re-running the query at execution time and processing 244 would widen the scope beyond what was reviewed. Only an explicit new all-results selection replaces the set with newly confirmed IDs and count, and it invalidates the previous execution confirmation.

A filter change also invalidates the confirmation

Sorting and pagination change how the same results are viewed, so preserve the selected IDs. The same applies to page size. The header checkbox shows a partial state when only some eligible rows on the current page are selected. Display total selection and current-page selection separately so hidden selections remain understandable.

For this example, applying a search term, filter or workspace change clears selection. Explain that near the filters beforehand and announce the clearing when applied. Even if the new query fails, do not restore the old set. Ignore an old all-results response when its query or selection generation is no longer current. A refresh also starts with no unsubmitted selection; accepted jobs are tracked separately.

Recheck the targets at confirmation time

A confirmation needs more than a number. Show the action, query scope, whether this is all results or individual selection, and exclusions. Editing selection while the confirmation is open invalidates it. Support keyboard selection and announce changed counts in text, without moving focus away merely because all-results selection completed.

Immediately before execution, the server checks current permission and eligibility for the same IDs. If one of 239 can no longer be processed, this design executes zero and presents the reason plus a new confirmation for 238. It never silently processes the remainder. Engineering must verify consistency between that recheck and the commit, including concurrent changes. After acceptance, later filters neither expand nor cancel that job; if its response is lost, check the existing job result first.

Ask AI for sequences that break the scope

A broad request to write a bulk-selection spec may return component names: checkbox, select all, confirmation dialog. Instead, I would supply the fictional counts and agreed membership rules, then ask for sequences where visible selection and actual targets diverge. A starting state, action, expected targets and execution decision can be compared directly with the rule table.

If a response merely says to update the count, ask what determines that count. Reject a proposal that silently adds new arrivals. Have it retain the 240-minus 1 set and carry that correction into copy, requests and QA. The prompt and follow-up below are reusable examples, not a claim that an AI conversation was executed.

Example prompt, not an executed AI conversation:
Review selection scope for a fictional exhibition-material list: 240 search results, 20 per page. The action adds a Needs review marker; no deletion or payment.
Page selection adds visible IDs. A separate all-results action freezes the accessible matching ID set and confirmed count on the server. Exclude one of 240 and keep 239 even when 5 new records arrive.
Keep IDs through sorting/pagination. Applied search/filter/workspace changes and refresh clear the pre-submission selection and confirmation. Discard stale selection/query responses.
Before execution, recheck current permissions, eligibility and confirmation version. If they change, execute nothing and ask for confirmation of the revised set. Editing selection invalidates prior confirmation. Accepted jobs keep their own fixed target set.
Find action sequences where the UI count and actual targets diverge. Return starting state, action, expected targets and whether execution is allowed. Do not invent unsupported server capabilities.
Example correction: after 240 selected minus 1 excluded plus 5 new arrivals, explain why 239 remain. Then remove permission to one selected record: revise the confirmation and QA so 238 are not executed silently.

Test identity as well as count

Do not stop QA after one successful select-all action. Move pages, sort, exclude a record and introduce new records. Compare expected IDs with the outgoing and accepted targets so a different set of equal size still fails the test. Include interactions during loading and delayed responses under controlled network conditions.

The table gives expected outcomes, not production test results. In the real environment, record the UI, request and server-confirmed set under the same operation. Avoid putting personal record content into analytics. Assistive-technology announcements need their own environment checks; a working article demo does not establish that integration.

Keep the choice in the proposal and transitions in the spec

The proposal should explain the task and why invisible matches need to be selected together. Record whether the backend can freeze that set. The specification connects selection, clearing, navigation, confirmation and accepted work to their exact text and data conditions. One line saying “supports select all” cannot replace either document.

Engineering verifies frozen membership, permissions and stale-response handling. QA compares actual IDs through the sequences. Support needs to trace the reviewed scope to the processed scope. After release, distinguish reconfirmation interruptions from wrong-scope reports; a lower count alone is not proof of improvement. Fill the handoff with your actual constraints, owners and evidence so the next person can continue from the decision.

Selection-scope handoff — fictional exhibition-material list
Goal: process exactly the scope the user confirmed. Add a Needs review marker;240 results and 20 per page are illustrative.
Page: selecting adds visible eligible IDs; clearing its checkbox removes only current-page IDs. Clear all removes every selection. Preserve IDs from other pages.
All results: a separate server operation freezes accessible matching IDs, time, query, selection version and actual count. Disable execution while preparing. If unsupported, omit this action. Failure leaves zero selected with a reselect route.
Membership:240 minus 1 equals 239. Five later arrivals are not included. Reselecting all results replaces the set and invalidates the previous confirmation.
Navigation: sorting, page and page-size changes keep the set. Applied search/filter/workspace changes clear selection and confirmation with advance notice and a status message. A failed query must not restore old selection. Refresh does not restore unsubmitted selection.
Responses: accept only the current query/selection generation. No execution during loading or selection preparation.
Display: Select 20 on this page / Select all 240 results /239 selected,19 on this page. Partial state reflects eligible rows on this page. Name row checkboxes clearly; support keyboard and announce counts without stealing focus.
Confirmation: connect operation, count, query scope, exclusions, capture time and selection version. Any selection edit invalidates it. Zero selected cannot execute.
Server: immediately before execution validate current permission, eligibility and confirmation version for the same IDs. If one of 239 is no longer allowed, execute zero; show the reason and ask to confirm 238. Engineering must verify consistency between recheck and commit.
After acceptance: preserve the accepted job target set and identifier. Later filters or refresh neither expand nor cancel it. Unknown response means checking that existing job before any retry.
Owners: planning covers scope/copy/transitions; engineering covers snapshot, permissions and concurrency; QA compares actual IDs; support uses execution scope and reasons. Analytics must not contain personal record contents.
Evidence: record build, owner, expected and actual targets, and evidence location after running the QA sequences. This is a design handoff, not a completed production integration test.

Sources and example conditions

An independent fictional exhibition-material list, informed by PatternFly and Carbon documents checked on 29 September 2026. Counts, frozen membership, clearing and pre-execution reconfirmation are example design choices. Written by WekeyLab AI without private company records or invented personal experience or results. AI prompts are examples. English and Chinese localize the same Korean case. Article interaction checks are separate from real production-list integration tests.

PatternFly — Bulk selection

Carbon Design System — Data table usage