Who Changed That Field? CRM History Audits with AI

A CRM field-history audit answers a different question than data hygiene ever will: not “is this record clean?” but “who changed this field, when, and was the change legitimate?” Every major CRM already captures that evidence — Zoho in its Timeline API, Salesforce in Field History Tracking and the Field Audit Trail add-on, HubSpot in per-property change history. Most teams never query it until something has already gone wrong.

That is the waste this guide targets. A field-history API turns “who changed this and when” from a support ticket — someone noticing a broken record, someone else spelunking through the UI’s history panel — into a query an AI agent can run on a schedule. Pipeline stages that moved backwards, customer-facing fields used as internal scratchpads, owner reassignments nobody remembers approving: all of it sits in the change log, attributed to a named user with a timestamp and the before-and-after values.

This guide covers what each vendor’s history API actually records, the tracked-field limits and retention windows that constrain what an audit can see, a four-step audit pattern that generalizes across platforms, and a worked example — catching deals that moved backwards through pipeline stages — that keeps a human approving every correction.

Three jobs get blurred together under “CRM data quality,” and the blur is expensive because each job needs different tooling. The first is data hygiene: deduplicating contacts, enriching missing fields, normalizing formats. It cares about the state of a record today and mostly ignores how the record got that way. We have covered that job in depth — the contact-management hygiene guide for the manual discipline, and the agent-run dedupe and enrichment pipeline for the automated version.

The second is agent observability: logging what your own AI agents did to the CRM, so their actions can be reviewed. That is the agent writing its own diary, and our agent audit-trail design guide covers it. The third job — this post — is forensic auditing of human edit history the CRM platform itself already captured: which person changed which field, when, from what value to what value. The evidence is generated passively by the platform whether or not you ever look at it.

The distinction matters operationally. A hygiene pipeline that merges two duplicate contacts destroys nothing you cannot reconstruct. An accountability audit is the opposite: its entire value is the reconstruction — proving a deal was demoted from a late stage to an early one, naming the user who did it, and checking whether anyone documented why. Hygiene tools do not answer that question, and hygiene metrics will not tell you it is happening.

The good news for anyone building an audit: the per-change record is remarkably consistent across vendors. Each entry identifies the actor, the field, the timestamp, the before-and-after values, and — crucially for triage — the origin of the change: a human in the UI, an API call, a workflow rule, an import.

Zoho CRM’s v8 REST API carries a dedicated Timeline endpoint per record. Its response includes done_by (name, ID, and profile of whoever made the change), field_history entries with the field’s API name plus old and new values, an audited_time ISO 8601 timestamp, an action type such as updated, added, tag_added, or owner_assigned, and a source distinguishing the CRM UI from API calls and workflow automation. Pagination defaults to 200 entries per page with a page token for more, and the endpoint returns an empty 204 when no timeline data matches your filters. The same timeline also covers non-field events — tasks, calls, meetings, emails, notes, and attachments — so one endpoint can answer “was there a note near this change?” as well as “what changed?”

Salesforce splits the job in two. Standard Field History Tracking writes per-object history you can query; the paid Field Audit Trail — sold as part of Salesforce Shield or licensed separately — extends coverage and archives history into a FieldHistoryArchive Big Object under a configurable HistoryRetentionPolicy, documented on Salesforce’s own developer reference. HubSpot takes a third route: its CRM object read endpoints accept a parameter — documented as propertiesWithHistory in developer-community material and in third-party connector documentation — that returns each requested property’s change history alongside its current value. We could not fetch HubSpot’s own developer reference page for this endpoint at the time of writing, so treat exact parameter spelling and request shape as something to confirm against the live docs rather than copy from here. Per the third-party connector documentation that has to match the real API to function, each history entry carries the value, an ISO 8601 timestamp, a source type such as API, import, or CRM UI, a source label, and the ID of the user who made the update.

One implementation nugget from the independent-connector world is worth stealing: one widely used third-party connector’s documentation notes that it deliberately skips syncing HubSpot’s hs_lastmodifieddate meta-field to avoid duplicate change tracking. If you build your own pipeline, apply the same rule on every platform — exclude last-modified meta-fields from the change stream, or every real edit will appear twice. For a broader map of how agents plug into these three platforms, our cross-platform CRM agent guide covers the integration surfaces beyond history.

An audit can only see what the platform kept. Before designing any recurring audit, map three constraints per platform: which fields are tracked at all, how long the history survives, and which mechanism — record-level history or the system-wide audit log — actually holds the answer to your question. The table below consolidates what we could verify, with the sourcing status of each figure stated plainly, because these numbers vary in how well they are documented.

Two smaller Zoho constraints round out the picture. Access to the Audit Log is role-restricted — non-admin users see only their own actions and their subordinates’, so an audit agent needs admin-scoped credentials to see the whole org. And per-feature caps hide in odd corners: in the Appointments module, the rescheduling tracker retains only the most recent 20 reschedule events per appointment. Assume every platform has similar small caps that only surface in feature-level documentation.

The pattern below generalizes across all three platforms because it depends only on what Section 02 established every history API returns: actor, field, timestamp, before, after, origin.

Step 1 — Define the question as a rule

A useful audit question is falsifiable per change entry. “Is our pipeline healthy?” is not auditable. “Which records moved backwards through a pipeline stage in the last 30 days, who moved them, and was a note added within a day of the move?” is. The rule encodes your operating policy — for example, “stage regressions require a documented reason” — so the audit is enforcement of something already agreed, not a fishing expedition.

Step 2 — Pull history via the API, on a schedule

The agent queries the record-level history API for the fields the rule touches — the stage field, the owner field, whichever customer-facing text field keeps being misused — over the audit window. This is where tracked-field limits from Section 03 bite: if the field is not tracked, there is no history to pull, and the first audit finding is “enable tracking on this field.”

Step 3 — Reconcile each change against the rule

For every change entry, the agent evaluates the rule: was the transition allowed? Was the actor someone with authority over that record? Does the origin field say a human did it in the UI, or did a workflow or API integration do it — which changes who you ask about it? Cross-referencing the same record’s notes and activity timeline turns “this looks wrong” into “this stage was demoted with no note within one day, by a user outside the record’s team.”

Step 4 — Escalate exceptions with the evidence attached

Everything that fails the rule goes to a named human reviewer as a proposed correction: the record, the change entry (actor, timestamp, before, after, origin), the rule it violated, and the proposed fix. The human approves, amends, or rejects. Only after sign-off does anything write back to the CRM. That review step is what makes the whole exercise an audit rather than another automation writing to production data on its own authority — a governance pattern we design into every CRM automation engagement.

Consider a sales team at example.com whose pipeline policy says deal stages move forward only — a deal that reached “Proposal Sent” should never silently return to “Qualifying.” Backwards moves happen anyway: a rep resets a stage to reuse a workflow, an integration overwrites the field during a sync, a manager demotes a deal without recording why. Each one quietly corrupts pipeline reporting, and none of them is visible in a dashboard that only shows current stage.

The audit agent runs weekly. It defines the stage order as an ordered list, pulls the stage field’s history for every deal touched in the window, and compares each transition’s old and new values against the ordering. On Zoho, that is one Timeline API call per candidate record, filtered to the stage field; the done_by block attributes each transition, and the source value separates human UI edits from workflow and API writes. On Salesforce, the same reconciliation runs over field history entries; on HubSpot, over the stage property’s history entries with their source types and updating user IDs.

The output is a short exceptions report, not a mutation: five deals moved backwards this week; three were API-sourced from the same integration user, suggesting a sync misconfiguration rather than human error; two were UI edits by named users, one with a note attached the same day (“client restarted procurement — reset to Qualifying, agreed with manager”), one with no note at all. The reviewer clears the documented one in seconds, asks the integration owner about the sync, and follows up on the undocumented demotion with the change entry as the conversation starter. If a correction is agreed — restoring the stage, relocating a misplaced note — it is applied by a person or by the agent under explicit per-record approval, and the correction itself lands in the same history trail, fully attributed.

The same skeleton audits field misuse. If consultants keep typing internal follow-up notes into a customer-visible field, the history API shows every write to that field, attributed and timestamped; the agent classifies each old-to-new diff (does the new value look like activity notes rather than the field’s intended content?), and the proposed fix — relocate the text to a proper note, restore or blank the field — carries its evidence with it. Attribution matters here: the fix is a training conversation with the two people who wrote most of the entries, not a memo to the whole team.

The retention picture across vendors — and across features within one vendor — is genuinely uneven, and it sets the deadline for every audit you have not run yet. Salesforce alone spans three windows: roughly 18 months for standard field history and 180 days for the Setup Audit Trail, both per third-party documentation, and up to indefinite for the paid Field Audit Trail, per Salesforce’s own developer reference. Zoho states no ceiling for the Timeline API — which is not the same as promising unlimited — while its separate Audit Log is a hard 3 years. HubSpot publishes no retention ceiling for property history in any of the pages we checked: the developer reference we attempted, the change-sources Knowledge Base article, and a major third-party connector’s documentation. That silence is a finding worth planning around, not a guarantee.

The practical implication: export and archive audit findings before the platform ages them out. None of the record-level trackers guarantees indefinite retention by default — the only mechanism in the table that can is Salesforce’s paid Field Audit Trail, and even there the default policy archives after 18 months rather than keeping everything hot. If a compliance question or a customer dispute arrives in year four, the Zoho Audit Log has already deleted year one, permanently. A monthly export of exceptions and their supporting history entries into storage you control costs almost nothing and removes the deadline entirely.

Here is the original-analysis point this whole guide builds to: in all the vendor documentation we reviewed for this piece, no platform offers a turnkey “find backwards stage moves” or “find misused fields” feature. The vendors ship the evidence layer — and as Section 03 showed, they ship it with real limits — but the reconciliation logic that encodes your rules is yours to build. That is not a criticism; a stage-regression rule or a field-usage policy is inherently org-specific. But it means the interesting question for 2026 is not “which CRM has the best audit log” — they are more alike than different — but “who turns their audit log into a scheduled, human-reviewed control first.”

Looking forward, the trajectory seems clear enough to plan around. History APIs are already attributing changes made by AI features — HubSpot’s documented change sources include its own AI and calculation systems alongside human and import origins — so the volume of writes needing review can grow faster than any team’s manual attention. Teams that establish the audit pattern now, while most CRM writes still come from humans and simple workflows, will have the control in place before agent-originated writes make it indispensable. Choosing where to start is straightforward: