Record history: attribution, batches and retention

What the per-record history records, why it names an automation rather than the person who configured it, how bulk operations are grouped, and how long any of it is kept. One cell's history Right-click any cell in the grid and choose History of this cell… to see every change to that one field on that one record: what it was, what it became, who did it and when. Earlier changes load on demand, and the list ends where the record was created. Three cells honestly have nothing to show, and the panel says which: a field whose history is switched off in its settings, a value worked out from other records — a lookup, rollup or formula has no changes of its own, and the panel names what it reads instead (Rig order lines → Line total (sum)), so you know where to look, and a cell nobody has changed since the record was made. The record’s own name column works too, and shows every time the record was renamed. Where history comes from History is written centrally, at the single point every save already passes through. That is why the grid, the peek drawer, an import, an automation and the public API all produce it identically, with nothing wired up per surface — and why a new write path gets history for free. It is the record-scoped sibling of the audit log rather than a replacement. The audit log is the workspace's forensic trail; this is the story of one row. See Comments, history & assigning people for reading the feed itself. Attribution is honest A change made by an automation is recorded as that automation — not as the person who configured the rule months ago. Attributing a rule's write to a human is the one way a history actively misleads: it says somebody was at their desk when nobody was. The same applies to the AI, to imports, to public form submissions and to inbound email. Each says what it actually was. What kind of thing wrote it Alongside the displayed label, every entry stores the kind of actor — a person, an automation, the AI, an import, a system write. The label is prose ("Automation · Overdue chaser"); the kind is a fact you can filter and count on. They are kept separate on purpose. Renaming an automation changes what future entries are labelled; it does not change what they were. Batch references A bulk operation stamps every row it touches with one batch reference. The four thousand rows a single import wrote are therefore one identifiable thing rather than four thousand unrelated edits, which is what makes it possible to see the shape of what happened rather than scrolling past its consequences. Retention History is kept for 24 months by default, changeable in Settings, or set to keep forever. A nightly pass enforces it, on the same schedule that already prunes automation runs and webhook deliveries. It is a duration rather than a cap on rows deliberately: "the last 500 changes" cannot answer whether a value was different in March, which is the question people actually bring to a history. History that was never captured cannot be recovered and there is no backfill, so the default errs long. Shortening it takes effect on the next nightly pass. Tips • Leave retention long unless you have a policy reason not to — you cannot get back what the prune removes. • When a value looks wrong, read the history before the audit log: it is scoped to the one record and already resolves ids to names. • If an automation is making changes you didn't expect, the actor label names it directly — you don't have to guess which rule ran. Good to know • Field keys and ids are stored raw and resolved to names when you READ the feed — so history shows what things are called NOW, not what they were called at the time. • Values in a diff are capped in length, so one enormous long-text edit shows a truncated before and after rather than the whole document. • Setting retention shorter takes effect on the next nightly pass and is not reversible — the rows are gone, not hidden. Who can do what • Seeing a record's history needs view access to that record; entries never reveal fields the reader cannot see. • Changing the retention setting is Admin-only, and applies to the whole workspace.