Bulk selection and actions
Select the records you mean, choose an action, and Connect applies it to each one through the service that owns it. There is no bulk statement that writes past that service, so every row is validated on its own terms. The consequence is the thing to understand before you start: a bulk action can partly succeed, and it reports what happened to each one.
Build the set with filters, not with the mouse#
Filter the sheet until it contains exactly the records you mean, and read the count.
Result The set is defined by a condition you can re-read, rather than by which ones you managed to tick.
Select the filtered set.
Result Selection follows the filter, so nothing off-screen sneaks in and nothing you meant to include is left out because you had not scrolled to it.
Choose the action and read what it says it will do.
Result The count and the change are both in front of you before anything is written.
Run it, then read the result summary.
Result You learn how many rows changed and which were refused, with the reason for each refusal.
Scroll-and-tick selection on a virtualised sheet is how people accidentally act on the wrong set: what you can see is a fraction of what matches, and the two are easy to confuse. Filtering first makes the set reproducible, which also means you can check it afterwards.
One action, many calls#
A bulk action is not a single write. It is the same change asked of the owning service once per row, so each row is validated, each is audited, and each can be refused independently. That is slower than a single statement and it is the property that keeps the grid honest: a rule that protects one record protects it just as much inside a selection of five hundred.
| Property | What it means for you |
|---|---|
| Partial success is possible | Some rows change, some are refused; the summary says which |
| No silent rollback | Refusals do not undo the records that already succeeded |
| Every row is audited | The trail shows the individual changes, not one aggregate entry |
| Time grows with the set | A very large selection takes noticeably longer; that is work, not a hang |
| Rules still apply | Compliance, suppression and validation refuse a record inside a bulk action exactly as they would one at a time |
Reading a partial result#
A summary saying most rows changed and a few did not is the normal, informative outcome — not a failure. The refusals usually share a cause, and finding it is more useful than retrying.
- Refused on validation
- Those records hold values the change would make invalid. Fix them, then repeat the action on just those.
- Refused by a rule
- A suppression or a compliance entry protects the record. That refusal is the rule working.
- Refused as unchanged
- Those records already had the value. Nothing was written and nothing needs to be.
- Nothing happened at all
- The action was not applicable to that sheet, or the selection was empty by the time it ran. Check the filter and the count.
What bulk actions do not do#
- They do not send anything. Changing many records is not a way to contact many people. Outbound work runs under autonomy and its own allowances, whatever the grid was used to select.
- They do not reach another workspace. The selection is bounded by the sheet, which is bounded by your workspace.
- They do not offer an undo button. Reversing a bulk change means applying the opposite change to the same set, which is another audited action rather than an erasure.
- They do not create records. Bringing new ones in is import, which validates every row before writing any.
Questions#
How many rows can I act on at once?
The practical limit is time rather than a fixed number, because every row is a separate call to the owning service. Work in filtered batches that mean something — one stage, one owner, one month — and the results stay legible as well as fast.
If one row fails, is the whole action cancelled?
No. Rows that succeeded stay changed and the refused ones are listed with their reasons. Treating a mixed result as a failure is the mistake here: it is a report, and it usually points straight at a data problem worth fixing.
Can the Assistant run a bulk change for me?
It can propose changes through its own tools, with the same service and the same rules underneath. What it cannot do is act outside the authority it has — see what the Assistant may not do.