CRM Audit Trail: See Who Changed a Deal Field and When

A deal's close date moves from this quarter to next. Nobody remembers approving it. The rep says they didn't touch it. The sales manager is sure they didn't either. Was it a workflow rule? An integration syncing from a calendar tool? A model-drafted update somebody clicked "approve" on without reading closely? The CRM shows the new value. It does not show how it got there.

This is a familiar moment for anyone who has run a pipeline review long enough: a field is wrong, or just different, and nobody in the room can say why. The deal amount shifted by a few thousand dollars. A deal reopened after being marked Closed Lost. A stage jumped backward. Each of these is a two-minute problem if you have a record of who changed what and when. Each is a half-hour argument if you don't.

That record is the CRM audit trail, and most teams only discover they don't really have one at the exact moment they need it.

Why CRMs Don't Just Remember This For You

A CRM field is designed to hold a current value, not a history of values. When a rep edits a deal's amount, the old number is gone unless something was specifically built to keep it. That something has to be configured, and in every major CRM, it is off by default for most fields.

There are also more sources of change than most teams account for. A field can be updated by:

• A rep editing it directly in the UI
• A workflow or automation rule firing on a trigger
• A third-party integration syncing from email, calendar or e-signature tools
• The API, used by an internal script or an AI tool drafting an update from a call transcript

Native CRM history usually blurs the last two into one generic "changed by integration user" or "changed by API" entry. It tells you something happened, but not what triggered it, and that is exactly the distinction a sales leader needs when a model-assisted update turns out to be wrong. If your CRM data isn't ready for AI sales tools yet, a missing audit trail is one of the concrete reasons why: you can't trust an AI-assisted workflow you can't audit.

Then there is retention. Even when history tracking is turned on, it is rarely unlimited. Fields age out, limits apply per object, and a team that assumes "the CRM has a record of everything" usually finds out otherwise during a commission dispute or a board-meeting question about why last month's forecast and this month's don't reconcile, which is the same root cause behind CRM data errors that cause commission disputes.

What Each Major CRM Actually Gives You

The three CRMs most small and mid-size B2B teams run on each handle this differently, and the differences matter when you're deciding which fields to protect.

Salesforce: Field History Tracking and Field Audit Trail

Salesforce's native Field History Tracking records the old value, the new value, the user who made the change, and the exact timestamp, for whichever fields you turn it on for. The catch: it is opt-in per field, capped at 20 fields per object on standard Salesforce, and it is not retroactive. Enable it today and you get a trail starting today, not a reconstruction of everything that already happened to that deal.

For longer retention or more fields, Salesforce offers Field Audit Trail as a separate, paid feature aimed at compliance use cases. If your sales org is in a regulated industry, or an acquirer's due diligence team is going to ask for deal-level change history (the same scenario covered in sales pipeline due diligence before you raise), that's the feature to evaluate, not the free 20-field default.

Pick your 20 fields deliberately: stage, amount, close date, forecast category, and owner cover most of what actually causes disputes. Don't burn the cap on fields nobody argues about.

HubSpot: Property History, With Limits

HubSpot tracks property history at the record level. Open a deal, click into any property, and "View Property History" shows a timestamped log, including whether the change came from a rep, a workflow, or an integration, which is a real advantage over tools that only log "something changed."

The limitation is retention depth rather than visibility: property history on standard accounts keeps a capped number of historical values per property per record rather than an unbounded log, so a field that gets edited constantly over a long sales cycle can lose its earliest entries. Enterprise accounts get a broader, centralized audit log under Settings, which is the better option if change history needs to survive a long B2B sales cycle, the kind described in how to keep your CRM accurate through a long sales cycle.

Pipedrive: The Changelog Tab and API

Pipedrive's version lives in plain sight: open any deal's detail view, go to History, and the Changelog tab lists field-level changes with old value, new value, user, and timestamp. It's one of the more accessible native implementations because you don't have to click into each field separately.

The same data is exposed through Pipedrive's API changelog endpoint, which is useful if you want to pull change history into a reporting layer instead of reading it deal by deal. Worth knowing before you build on it: some teams have reported custom field changes missing from related API endpoints, so if you're relying on the API for compliance-grade reporting rather than spot checks, verify the output against the UI changelog for a sample of deals first.

Comparing the Three in Practice

None of the three is a complete answer on its own, but the trade-offs differ. Salesforce gives you the cleanest record once Field History Tracking is on, at the cost of a 20-field cap and no retroactive history. HubSpot gives you source attribution (rep vs. workflow vs. integration) for free at the record level, but standard accounts cap how many historical values survive per property, so a field edited dozens of times over a long cycle can lose its earliest entries. Pipedrive's Changelog tab is the easiest to read without extra setup, and its API makes the same data queryable, though a few teams have reported gaps in custom field coverage worth spot-checking before you build reporting on top of it.

If your sales org runs on more than one of these, for example after a merger or when a sales team moves CRMs mid-year, the practical answer is not to expect parity. Document which fields are tracked and for how long in each system, and treat any field outside that list as unverifiable if a dispute comes up. That's a smaller problem than it sounds: most disputes cluster around the same four or five fields, so the coverage gap is narrower once you've mapped it.

What Good Audit Trail Practice Looks Like

Turning on field history is necessary but not sufficient. The teams who actually use this well do a few things consistently:

They pick a short list of fields that matter, not everything. Deal amount, stage, close date, and forecast category drive almost every dispute and every forecast miss. Track those deliberately rather than spreading a 20-field cap across fields nobody questions.

They separate "who" from "what triggered it." A change made by a rep reading a signed contract is a different kind of event than a change made by a workflow rule or an AI-drafted update a rep approved without close review. If your tooling can tag the source, use that. This is the same guardrail that matters when deciding whether AI should write to your CRM automatically: the safer pattern is an AI-drafted suggestion the rep reviews and approves, and the audit trail should show that approval as its own event, separate from the suggestion itself.

They review the trail during pipeline reviews, not just during disputes. A five-minute scan of what changed since last week, for the fields that matter, catches a sandbagged deal or a model-drafted update that slipped through before it corrupts the forecast. This fits naturally into how to run a pipeline review meeting as a standing agenda item, not a special investigation.

They don't treat native history as a permanent compliance record. If you need change history to survive for years, across an acquisition, a due diligence process, or a regulatory requirement, native field history in any of these three tools is a starting point, not the final answer. Plan for a paid audit feature, a data warehouse export, or a reporting layer that captures snapshots on its own schedule.

Checking Your Own Setup

A quick audit takes under 15 minutes:

1. Pick your five most disputed fields: usually amount, close date, stage, forecast category, owner.
2. Confirm field history or property history is actually turned on for each one. In many orgs, nobody checked after the CRM was first set up.
3. Pull up three deals that changed hands between reps or changed stage unexpectedly, and see whether you can actually answer "who did this, and from where" for each one.
4. If any AI tool, workflow, or integration writes to these fields, confirm its changes are distinguishable in the trail from a rep's manual edit.
5. Write down your retention limit for each tool. If you don't know it, assume it's shorter than you'd like and plan accordingly.

A CRM that can't answer "who changed this and when" for the handful of fields that drive your forecast isn't fully trustworthy yet, no matter how clean the pipeline looks on the surface. Field history and changelogs exist in every major CRM for exactly this reason. The gap is almost always that nobody turned them on for the right fields, or nobody looks at them until something has already gone wrong.

If you want a sense of how exposed your own pipeline data is right now, check your pipeline coverage with the free calculator. It won't show you a changelog, but it will show you where the numbers you're relying on don't add up, which is usually the first sign that an untracked change happened somewhere upstream.

Frequently Asked Questions

What is a CRM audit trail?

A CRM audit trail is a record of changes made to a field over time: the old value, the new value, who made the change, and when. Salesforce, HubSpot and Pipedrive each ship a version of this, but none of them turn it on by default for every field, and each has real limits on retention and coverage.

Does Salesforce track field history automatically?

No. Salesforce Field History Tracking has to be enabled per field, up to 20 fields per object on standard Salesforce, and it only starts recording from the moment it is turned on. It does not reconstruct changes that happened before tracking was enabled, and longer retention requires the separate Field Audit Trail feature.

Can HubSpot show who changed a deal property?

Yes, on the record level. Open a deal, click into a property, and choose View Property History to see a timestamped log of changes, including whether the change came from a rep, a workflow, or an integration. Enterprise accounts also get a broader audit log under Settings, but standard property history keeps only a limited number of historical values per property, so it is not a permanent record for heavily edited fields.

Does Pipedrive have a changelog for deals?

Yes. Every deal's detail view has a Changelog tab under History showing field-level changes with the old value, new value, user, and timestamp. The same data is available through Pipedrive's API changelog endpoint, though some custom field changes have been reported missing from certain API responses, so teams relying on it for reporting should spot-check the output.

Should AI-drafted CRM updates look different in the audit trail than manual edits?

Yes. If an AI tool is drafting updates to deal fields from call notes or email threads, the audit trail should record the update's source as AI-drafted and record the rep's approval as a separate event, not blend both into a single generic edit. Without that distinction, you lose the ability to tell what a human verified from what a model guessed.