Editing a record in the grid, end to end
Typing into a cell sends one change to the service that owns that record. The grid paints your value immediately so the sheet stays usable, then replaces it with whatever the service stored — which is not always what you typed, because a service may normalise a value as well as accept it. The stored record is the answer, and the row shows it within the same interaction.
The path one cell edit takes#
- Trigger — you commit an edit in a cell on one of the thirteen sheets in
#/data. - User event — the record's identifier, the field and the new value go together. The row's position on screen is not part of the request.
- Authentication and workspace resolution — your session decides the workspace before the record is loaded; the operator and customer sessions reach the same service by different API paths.
- Ingest — the value arrives as text and is coerced to the field's real type. A date column takes a date, not a sentence about one.
- Canonical record — the record is loaded through its owning service. The grid holds no copy that could be written back over it.
- Reasoning — none. You stated the value; nothing infers what you meant by it.
- Knowledge, memory and rules — the service validates, applies whatever rule governs that field, and may normalise the value into its stored form.
- Autonomy and approval — not consulted. You are the actor and the change stays inside the workspace.
- Action — the field is written, together with any side effect the change implies, exactly as it would be from the record's own screen.
- Result — the stored value comes back and replaces what you typed in the cell. A refusal restores the previous value instead.
- Relationship and timeline — a change that matters to a person or company appears on their timeline; a change to a private field does not.
- Audit and usage — one entry records what changed, from what to what, and who did it. Nothing is metered: an edit is not model work.
Two of those stages are easy to miss because they succeed silently. Coercion turns your text into the field's type, and normalisation turns an acceptable value into the canonical one — which is why a cell can come back written slightly differently from the way you typed it, with nothing wrong.
Stage by stage, with what can fail#
| Stage | What you see | What changes | What can fail |
|---|---|---|---|
| Enter edit mode | The cell opens | Nothing | A derived column does not open at all |
| Type | Your value, unvalidated | Nothing | Nothing is sent while you are still typing |
| Commit | The cell shows your value immediately | Nothing yet — the paint is optimistic | Navigating away here abandons the edit |
| Service call | A brief pending state on the row | The record, if it is accepted | Validation, permission, a rule, or a stale row |
| Reconcile | The stored value replaces yours | Nothing further | A value that comes back different is normalisation, not an error |
| Repaint | The row may move | Nothing | A sort or filter on that column relocates the row you just edited |
Why the grid asks instead of writing#
#/data renders thirteen sheets over records that already have owners: companies, people, leads, prospects, follow-ups, deals, conversations, calls, cases, onboarding, knowledge, files and memory. Each one has a service that defines what a valid record is, and the grid calls it rather than reimplementing it.
- One definition of valid. A rule written once is enforced on the record's own screen, in the grid, through the Assistant's tools and in an import.
- Side effects are not skipped. Changing a lifecycle stage from a cell runs the same journey logic as changing it anywhere else.
- The audit entry is identical whichever screen you used, so a history does not depend on knowing where somebody was standing.
- A new rule needs no grid change. The sheet inherits it the day the service gets it.
The visible consequence is that the grid is fast to read and deliberate to write. A sheet scrolls like a spreadsheet because rows are virtualised; an edit takes a round trip because a record is not a cell.
Habits that make editing here pleasant#
Filter to the rows you actually mean before you start editing.
Result You stop scrolling past neighbours, and a mis-click lands on a row that at least belongs to the same problem.
Avoid sorting on the column you are about to edit.
Result Rows stop jumping out from under you the moment they are saved.
Save the filter as a view if you will return to it.
Result The next session starts where this one ended instead of being rebuilt from memory.
When a cell comes back different from what you typed, read it before retyping.
Result Nine times in ten it is the canonical form of the same value, and retyping simply produces it again.
For the same change across many rows, select and use a bulk action.
Result One reviewed selection beats forty individual edits — see editing many records at once.
If an edit is refused rather than normalised, the grid would not save an edit lists the six reasons in the order they are worth checking.
Questions#
Why did my value come back written differently?
The service normalised it. A date typed one way is stored in the field's own form, an identifier is stored canonically, whitespace is tidied. The record now holds the value in the shape everything else in Connect expects, which is why the same record reads consistently on its own screen and in an export.
Is an edit made here recorded differently from one made on the record's screen?
No. Both go through the same service and produce the same audit entry, with the before and after values and the person who made the change. That is the point of routing everything through the owning service: the history does not record which screen somebody happened to use.
What happens if two people edit the same cell at once?
Each edit is a separate call, so the later one is applied to the record as it stands after the earlier one. The grid you are looking at can be showing a row loaded before the other change; refreshing the sheet re-reads the stored record. The audit entries keep both changes in order.