A HubSpot audit checklist, in the order problems spread
Alexandra-Emily Kokova
Published 6 November 2026 - 7 min read
Bad data in HubSpot usually starts at an entry point and spreads into reports. An audit read in that order finds the cause before it gets to the symptoms.
A HubSpot audit is a read-only pass over a portal before anything gets fixed. Check, in this order: users and seats, the ways data gets in, properties, lifecycle and deal stages, workflows, integrations, duplicates, marketing contacts, then reports. For each finding write down the count, where it lives and who owns the fix.
On this page
Most HubSpot portals get audited when something has already gone wrong: a report the board doesn’t trust, a migration coming up, a renewal that costs more than expected. The checklist is the same in each case. Read it in order, and change nothing until the reading is done.
What a HubSpot audit is
A HubSpot audit is a read-only pass over a portal: users, data, automation, integrations and reports. It ends in a list of findings with counts and owners. Cleaning up is the next step and a separate one. Merging duplicates during the audit hides how many there were, and that count is part of the evidence.
Before you start
You need a Super Admin, or a user who can see every record and open settings. Without view-all access the counts come out low and nobody notices. Note the date you start, because property history and workflow logs only make sense against it.
Some tools depend on the subscription. The Data Quality area, under Data Management, is available on most paid hubs. Duplicate alerts, the property Anomalies tab and automated formatting fixes need Data Hub Professional or Enterprise. Workflow enrollment history goes back six months, so older problems have to be read from property history instead.
The checklist
One row per area, in the order to read them. The last column is what a problem tends to look like when it’s there.
| Area | Check | What trouble looks like |
|---|---|---|
| Users and seats | Settings, Users & Teams: seat type and last active date for everyone | Paid seats on people who haven’t logged in for 60 days. More Super Admins than people who manage billing and security. |
| Ways data gets in | Forms, imports, integrations and chat. Property history shows the source of each value. | A form or import nobody owns. Hidden form fields writing to properties people also edit by hand. |
| Properties | Data Quality, Property Insights: the Unused and No data lists | Two properties with the same meaning. Free-text fields where a dropdown was meant. |
| Lifecycle stage | Which workflows, forms and integrations set it | More than one thing setting it. Contacts moving backwards. Customers still marked as leads. |
| Deal pipelines | Stages, required properties per stage, open deals by close date | Open deals with a close date in the past. Stages that nobody moves deals out of. |
| Workflows | Automation, Workflows, the Health tab and at-risk workflows | Workflows with errors nobody reads. Two workflows setting the same property in opposite directions. |
| Integrations | Connected apps and private apps: who installed each and what it writes | Apps installed by someone who has left. Syncs that overwrite fields people maintain. |
| Duplicates | Data Quality, Manage Duplicates, for contacts and companies | A duplicate count that keeps rising after every merge, which points back to an entry point. |
| Marketing contacts | Marketing against non-marketing counts, and the contact tier you pay for | Contacts billed as marketing who haven’t been emailed in a year. |
| Reports | Dashboards and the properties each report depends on | Reports built on properties flagged earlier in the audit. Dashboards nobody opens. |
Why this order
Users come first because every later finding needs an owner, and the user list shows who is still around to own things. A workflow built by someone who left last year has nobody to ask, which changes how carefully it gets touched.
Entry points come before the data. A duplicate problem that started with a form will refill as fast as anyone merges, so the form goes on the findings list with the duplicate count beside it. The same goes for lifecycle stages: if a workflow, a form and the chat tool all set the stage, fix which one is allowed to before correcting the values.
Reports come last because they sit on top of everything else. A dashboard nobody trusts usually reads a property that was flagged two rows earlier.
Writing up what you find
Each finding gets one line: what it is, where it lives, how many records it touches, who owns the fix and what the fix is. "Lifecycle stage set by two workflows and the website chat, 1,240 contacts moved backwards since March" is a finding. "Lifecycle stages are messy" isn’t.
Sort the list by what the problem breaks, not by how easy it is to fix. Entry points and lifecycle problems go first, because they keep producing bad data until they’re fixed. Unused properties and dead dashboards go last. They clutter the portal without producing new bad data. The clean-up itself follows the same order as cleaning up a messy HubSpot.
What an audit can’t see
The portal shows how HubSpot is configured. It doesn’t show how people work around it. A field can be full and still wrong, because reps type whatever lets the deal move to the next stage. A short conversation with two or three users, and ten minutes watching one of them log a call, catches what the settings can’t.
Billing is the other blind spot. The audit shows seats and marketing contacts, but the price for each sits in the contract, and seat types changed again in October 2026. Read the billing page alongside the user list.
Run it again before a migration, before a large renewal, and once a year otherwise.