Editing many records at once, end to end
A bulk edit is not one write. The grid turns your selection into one call per record against the service that owns that record, applies each on its own, and reports what happened row by row. Nothing is written by the grid itself, so a field a service refuses from its own screen is refused here too — and a run that changes forty rows out of fifty is a normal outcome, not a fault.
The path a bulk edit takes#
- Trigger — you select rows on a sheet in
#/dataand choose an action. - User event — the selection, the field and the new value are posted together; the sheet you are on decides which record type is in play.
- Authentication and workspace resolution — the session resolves the workspace before any row is read, and an operator session and a customer session reach the same service by different API paths.
- Ingest — the selection is expanded server-side into a list of record identifiers, not row numbers, so a re-sort between selecting and confirming cannot move the target.
- Canonical record — each identifier is loaded through its owning service: people, companies, leads, prospects, follow-ups, deals, conversations, calls, cases, onboarding, knowledge, files or memory.
- Reasoning — none. A bulk edit is a stated change, not an inference; no model is asked what you meant.
- Knowledge, memory and rules — the service applies its own validation and any rule that governs that field, exactly as it would for a single edit made anywhere else.
- Autonomy and approval — the actor is you, so channel autonomy does not apply. What does apply is your permission on that record type, and the fields the service will not accept from any caller.
- Action — the change is applied per record. There is no cross-record transaction: record 12 succeeding does not depend on record 13.
- Result — a per-row outcome comes back, changed or refused with a reason, and the grid repaints the rows that moved.
- Relationship and timeline — a change that matters to a relationship lands on that person's or company's timeline the same way a change made on their own screen would.
- Audit and usage — every applied change is recorded against you with its before and after, which is what makes a bulk edit explainable months later.
The stage worth reading twice is the fourth. Expanding a selection into identifiers rather than positions is the difference between an action that means *these forty companies* and one that means *rows 1 to 40 of whatever the sheet looks like when the request lands*.
Stage by stage, with what can fail#
| Stage | What you see | What changes | What can fail |
|---|---|---|---|
| Select | A count of selected rows | Nothing yet | A filter still applied means the selection is narrower than you think |
| Choose the action | The field and the value to set | Nothing yet | A field the sheet displays but the service does not accept is not offered |
| Confirm | A progress indication | Nothing until the first record is written | Closing the tab mid-run stops the run; records already applied stay applied |
| Apply | Rows repainting as they land | One record per successful call | A single record can be refused on its own validation without stopping the rest |
| Report | Changed and refused counts, with reasons | Nothing further | A reason you cannot act on usually means a rule, not a defect — see the grid would not save an edit |
| Audit | Nothing on the grid | One entry per applied change | Nothing is recorded for a refusal beyond the refusal itself |
Why the grid does not write anything itself#
#/data is a view over thirteen sheets, not a second copy of the business. Every change it makes is handed to the service that owns the record, which is the same code path the record's own screen uses and the same one the Assistant's tools use. That single rule has three consequences you will meet in practice.
- A field a service refuses cannot be written from a cell. Pricing is the clearest example: it is not a column you can get past by editing it somewhere else.
- Validation is identical everywhere. A date the follow-up service rejects on the Follow-ups screen is rejected in the grid, with the same wording.
- Side effects still happen. Moving a deal's stage from the grid runs the same journey logic as moving it on the pipeline, including anything that lands on a timeline.
The cost of that design is speed: forty records are forty calls, and a large run takes visible seconds rather than being instant. The benefit is that there is exactly one definition of what a valid record is, and the grid cannot become a back door around it.
When some rows change and others do not#
- A handful refused with the same reason
- One rule is catching them. Fix the underlying value on those records, or change the rule, then re-run on the smaller selection.
- Refusals scattered across unrelated reasons
- The selection is probably wider than the intent. Filter first, check the count, then act.
- Nothing changed at all
- Either your permission on that record type does not allow it, or the value was already what you set. The report distinguishes the two.
- Changes applied but not visible
- The sheet is sorted or filtered on the field you just changed, so the rows moved out of view. Clearing the filter brings them back.
Re-running a bulk edit over rows that already have the new value is safe: setting a field to what it already holds is applied as a no-op by the service rather than counted as a change. That is what makes *fix the refusals, run the whole selection again* a reasonable habit instead of a risk.
Questions#
Can a bulk edit be undone in one action?
Not as a single reversal. Each applied change is recorded individually with its before and after, so the information needed to reverse a run exists, but the grid does not offer a one-click undo of an entire bulk action. Treat the selection count on the confirmation as the last cheap moment to change your mind.
Does the Assistant use the same path when I ask it to change many records?
Yes. data_update and data_create call the same owning services with the same validation, and the Assistant's rights are narrower than yours rather than wider — it has no pricing authority and it cannot clear a do-not-contact entry. Asking it to do something the grid refuses does not make the refusal go away.
How many rows can I select at once?
The interface does not publish a fixed ceiling, and none is recorded in the sources this page is built from. What is true is that cost grows linearly with the selection because each record is applied separately, so a very large run is better split into filtered passes you can check between.