HubSpot Property History Audit

A HubSpot property history audit usually starts with a simple question: why does this record say what it says. HubSpot’s own documentation answers that question well for a single record, opening a right-hand panel with the value, the change source, and the date and time it changed, searchable and restorable on the spot. The trouble shows up one step later, when the question changes from “what happened to this record” to “what happened across our database, and which tool actually did it.” That second question runs straight into two separate, less obvious limits: a source column built from roughly fifty fixed categories, only a few of which HubSpot documents as naming names, and no way to see many records’ history at once except a manual export with its own fixed revision cap.

HubSpot Property History Audit: What The Record Actually Shows

Per HubSpot’s own documentation on viewing a record’s property history, a HubSpot property history audit at the record level is genuinely thorough: “Review the past property values for an individual record, either for a single property or for all properties.” Two separate views exist inside a record, and they are not the same feature scaled down or up, they show different scopes of the same underlying log.

The single-property view is reached by hovering a property in the left sidebar, and it is deliberately narrow: HubSpot’s own documentation states the panel lets someone “review the history, change source, and date of the change for the selected property,” one property, one record, nothing else. The all-properties view sits behind the record’s Actions menu instead, and widens the scope to the whole record at once: it lets someone “view the historical values for all properties of the record,” “view the date and time a change occurred,” “view the source of a change,” and “search by property name (e.g., Deal Score) or change source (e.g., HubSpot AI).” A value can also be reverted directly from this panel, since HubSpot’s own documentation confirms someone can “restore a property value” by hovering a row, clicking Actions, then clicking “Restore all from this source.”

Both views stop at the record boundary. HubSpot’s own documentation says so directly, in the same sentence that introduces the feature: “If you want to view historical data for a property across all records, learn how to export a property’s history instead.” That single line is the hinge the rest of this article turns on. A HubSpot property history audit that only needs to explain one record’s current value is fully served by the record UI. An audit that needs to compare many records, or trace a pattern across a database, is already being pointed somewhere else before it has even started.

Who Changed It, or Which Tool Did: Reading The Change Source

The source column is where a HubSpot property history audit either gets a name or gets a category, and HubSpot’s own documentation is specific about which sources get which. Per HubSpot’s own documentation on change sources: “Within HubSpot, you can view a record’s source to understand how a record was created or view a record’s property history to see how its property values have been updated over time. The source values below show which tool, user, or process updated the record.” Around fifty named sources follow, and they are not documented with equal detail.

A manual edit gets a name attached, by design: “CRM UI: a manual action in HubSpot (e.g., manually create a contact). If a user makes the change, their profile name and email address will be listed.” That is the clearest possible attribution HubSpot’s own documentation offers, a specific person, by name and email, tied to a specific change. Three other sources get comparable specificity. A custom agent change is documented as showing an actual, clickable name: “Custom Agent: by a custom agent (BETA). The agent’s name will appear as a link in the source. The source will also show who created the agent.” A separate, non-BETA agent source is documented the same way: “Customer Agent: by the customer agent. The configured agent name is also displayed.” A deduplication change goes further still, naming the mechanism behind the change: “Data Quality: by the manage duplicate records tool. The value will display additional details such as standard or custom duplicate rule and automatic or manual change.”

Three of the most common automation-driven sources are documented with no such elaboration. “Workflow: a workflow.” “Integration: a connected app.” “Batch Update: a batch API endpoint, or an internal batch migration.” Nothing in HubSpot’s own change-sources documentation states that the Workflow entry in a property’s history names which specific workflow made the change, or that the Integration entry names the specific action a connected app took, or that Batch Update identifies the specific migration or API call responsible. Set against the explicit extra detail promised for CRM UI, Custom Agent, Customer Agent, and Data Quality, the absence for these three reads as a real, documented gap rather than an oversight in the page’s phrasing: a value that changed via a workflow shows up as changed by “a workflow,” full stop, in the same source column that would have named a person for a manual edit.

Retention Limits and What’s Actually Exportable

A HubSpot property history audit that needs to look across many records at once has exactly one documented route there, and it is not a report. Checking HubSpot’s own documentation on the custom report builder’s data sources directly, property history, property changes, or any change-log source does not appear anywhere among the objects, assets, and events it lists as reportable. The only documented multi-record route is described on a separate page, HubSpot’s own documentation on exporting property history: “To view the history of a property’s values, you can export its historical data. This export includes only records that previously had or currently have a value for the property.” That export requires specific permissions, stated directly: “CRM Export and [Object] Edit All permissions are required to export a property’s historical data.”

The export itself is not unlimited. HubSpot’s own documentation states a fixed retention cap by object, and is explicit that the cap applies regardless of how the change was made: “the limit on the number of revisions saved in each property’s history is based on the object. The following limits apply to all revisions, including both those made within HubSpot and via API.” A high-frequency integration updating a property daily will exhaust that cap in weeks, at which point the earliest revisions are gone from what can be exported, not merely hidden from a shorter default view.

Access route	What it covers, per HubSpot’s own documentation	Many records at once	Retention limit
Single-property history panel	One property on one record: value, change source, date	No	Same underlying revision cap as export
All-properties history panel	Every property on one record: value, date and time, source, searchable and restorable	No, still one record	Same underlying revision cap as export
Export property history	Current and historical values, plus which user or tool triggered each update, for every record with a value	Yes, but as a static exported file, not a live report	Up to 45 revisions for contact properties; up to 20 for company, deal, ticket, and custom object properties
Custom report builder	Not documented as an available data source	Not applicable	Not applicable

The export file itself carries one more practical trap worth naming: HubSpot’s own documentation notes “the export file uses the UTC (Coordinated Universal Time) time zone for change dates. You may need to convert the time to your local time zone to confirm the date and time the property value was updated.” A property that appears to have changed just after midnight in the export may, once converted, have changed the previous evening, which matters when the audit is trying to line a change up against a specific meeting, call, or campaign send.

Undo, Restore, and What Manual Correction Can’t Touch

Reading a HubSpot property history audit is one task, correcting what it turns up is another, and HubSpot’s own documentation draws a sharp line between the two based on what made the change in the first place. Per HubSpot’s own documentation on undoing property value changes: “In certain scenarios, undo individual property value changes made to records from CRM cards or index pages. This means manual undo actions do not apply to changes made from the following: workflows, API, or connected apps. Instead, restore changes by workflows within a workflow.” A change made by a person in the UI gets a one-click Undo; the same value changed by a workflow does not, on the same record, in the same panel.

Bulk correction exists as a separate, tier-gated tool rather than an extension of the record-level Undo. HubSpot’s own documentation states: “You can undo changes made to multiple records of an object within 14 days by restoring CRM data. Depending on your subscription, you can also create a backup of your CRM records and property values.” Access to that tool is not universal the way viewing or exporting history is: “A Starter, Professional or Enterprise subscription is required to use the back up CRM data tool.” Every source cited earlier for viewing, searching, and exporting property history states it is available on “All products and plans”; the bulk restore path that acts on what a HubSpot property history audit finds sits behind a plan requirement that the audit itself does not.

Where Teams Get This Wrong

The first common mistake is treating a Source value of “Workflow” as sufficient evidence to close an investigation. HubSpot’s own documentation states this entry only as “a workflow,” with no further identifying detail documented, unlike the CRM UI, Custom Agent, Customer Agent, and Data Quality sources it sits alongside. Finding the specific workflow responsible means cross-referencing the change’s date and time against workflow enrolment history or a workflow audit separately, not reading it straight off the property history panel.

The second common mistake is assuming property history can be filtered or reported on across many records inside HubSpot without exporting anything. HubSpot’s own documentation on the custom report builder’s data sources does not list property history as reportable, and both the single-property and all-properties panels are scoped to one record. The export is not an inconvenient extra step around a report that also exists; per the cited documentation, it is the only documented route to multi-record history at all.

The third common mistake is assuming a bad workflow-driven or API-driven change can be fixed with the same Undo button that reverts a typo. HubSpot’s own documentation states plainly that manual undo does not apply to workflow, API, or connected-app changes, and that fixing those requires restoring inside the workflow itself, or running the back-up CRM data tool, which is not available on every plan.

The fourth common mistake is treating the export’s revision cap as a soft default rather than a hard ceiling. HubSpot’s own documentation states the 45-revision (contacts) and 20-revision (companies, deals, tickets, custom objects) limits apply to all revisions, including those made via API, so a property updated frequently by an integration can lose its earliest history from what is exportable well before anyone thinks to check.

Related Reading

For the CRM foundation this kind of audit runs against, see HubSpot Consultancy. For the automation layer that is often the “Workflow” behind an unexplained change, see HubSpot Workflow Version Control and Rollback Guide. For the wider discipline this kind of investigation sits inside, see RevOps Consultancy.

Go deeper: HubSpot Automation Audit Checklist for SaaS RevOps Growth · HubSpot CRM Data Hygiene · n8n Consultancy

Book your free audit

Frequently Asked Questions