A HubSpot audit checklist is worth having before you touch a portal you did not build, whether you have just joined as a RevOps hire, taken over from an agency, or inherited a CRM nobody has looked at properly in years. This expands Equanax’s own free-audit methodology into the full 27-check list, in the order that actually avoids wasted work: pipeline logic first, then data hygiene, then automation, then reporting last, because reporting inherits every problem upstream of it and auditing it first just produces a list of symptoms rather than causes.
None of the 27 checks below need special tooling. Every one is runnable with standard admin access, a spreadsheet, and the willingness to sample actual records rather than trust a dashboard’s summary at face value. What takes practice is telling the two kinds of check apart. Some checks reveal a design decision: why does this stage exist, why does this property matter, questions with a defensible answer even if you disagree with it. Others reveal decay: why is this workflow still enrolling contacts nobody uses that property for any more, a question whose honest answer is usually “nobody remembers.” A design decision gets discussed with whoever owns the portal before anything changes. Decay gets fixed.
Why a HubSpot Audit Checklist’s Order Matters
Most published audit checklists list checks alphabetically or by feature area, which feels thorough but wastes real hours. A check built on top of a broken pipeline stage structure is worthless: if stages do not represent how deals genuinely move, every downstream check, from automation to reporting, is measuring against a structure that is itself wrong. Data hygiene comes before automation for a similar reason, not just tidiness: a workflow audit checked against a portal full of duplicate contacts produces misleading results, since the same automation decision gets evaluated twice against what looks like two different records, and a routing or scoring check that looks broken might just be reacting correctly to duplicate data rather than to a genuine automation fault. Reporting comes last because it is where every upstream problem eventually surfaces as a wrong number, and starting there just produces a list of symptoms rather than the causes worth fixing.
Pipeline and Stage Logic: 7 Checks
| # | Check |
|---|---|
| 1 | Do stage names match how the sales team actually describes a deal’s progress, or are they the platform defaults nobody renamed |
| 2 | Does every stage have exit criteria a rep could explain, or is stage progression a matter of judgement |
| 3 | Are there stages nobody’s deals have moved through in the last two quarters |
| 4 | Does deal probability or forecast category align with stage, or has it drifted out of sync |
| 5 | Are required properties enforced at the stage where they actually become knowable, not all bundled at creation |
| 6 | Is there more than one active pipeline, and if so, is that deliberate or accidental sprawl |
| 7 | Do lifecycle stages (lead, MQL, SQL, opportunity, customer) match the deal pipeline’s own stages, or do the two disagree |
Check 3, the stage nobody’s deals have moved through recently, is the fastest way to spot a pipeline that has drifted from how the team actually sells. A stage sitting empty for two quarters usually means one of two things: either the sales motion changed and nobody updated the pipeline to match, or the stage was copied from a template at setup and never represented a real step in the first place. Either way, a rep working around a stage that does not reflect reality is a sign the pipeline needs rebuilding, not just relabelling.
Data Hygiene: 7 Checks
| # | Check |
|---|---|
| 8 | What’s the duplicate contact rate, sampled directly rather than assumed |
| 9 | What’s the duplicate company rate, and is there a merge policy at all |
| 10 | What percentage of required fields are actually populated on records created in the last 90 days |
| 11 | How many owned records have no owner, orphaned after someone left or a territory changed |
| 12 | Are there properties nobody uses any more, left over from a campaign or a tool no longer in the stack |
| 13 | Do custom properties have consistent naming, or does the same concept exist under three different property names |
| 14 | Is there a documented source of truth for which system owns which field, where more than one tool writes to HubSpot |
Duplicate contacts, check 8, compound silently in a way that makes them worse the longer they go unaddressed. Two records for the same person mean engagement history splits across both, so lead score and activity data undercount what that person has actually done, and any routing or scoring logic built on top evaluates the two halves separately rather than as one whole contact. A portal with no merge policy accumulates duplicates every time a form gets submitted twice or a list gets re-imported, which is why sampling the actual rate directly, rather than assuming it based on how the portal looks, is worth doing early rather than late.
Automation: 7 Checks
| # | Check |
|---|---|
| 15 | How many workflows are marked as active, and how many of those have actually enrolled a record in the last 30 days |
| 16 | For each active workflow, does someone on the current team know why it exists |
| 17 | Are there workflows with re-enrolment logic that could be double-enrolling the same record |
| 18 | Do any workflows depend on a property that a different, disabled workflow was supposed to populate |
| 19 | Are notification and alert workflows still routing to people who still work there |
| 20 | Is there a workflow that looks active but has silently stopped firing, checked via enrolment history rather than the toggle state alone |
| 21 | Are any workflows editing a property that’s also set by an external integration, creating a silent write conflict |
Check 15 and check 16 together are worth running before any of the others in this section, because the count of workflows that look active is nearly always higher than the count anyone can confidently explain. A portal that has been live for a few years commonly turns up more enabled workflows than anyone expects, and it is normal, not alarming, to find that a meaningful share of them have no clear, current owner who can say why each one exists. The point of the check is not to disable everything unexplained on sight; it is to build the list of candidates worth investigating properly before deciding what stays and what gets retired. This section covers portal-wide automation health across every category above; HubSpot Automation Audit Checklist for SaaS RevOps Growth goes deeper on the automation checks specifically, for a team that wants that piece in isolation.
Check 20, the workflow that looks active but has silently stopped firing, is worth a closer look because it is the one almost every audit finds and almost nobody catches on their own. A workflow’s toggle can read as active while its actual trigger condition has stopped matching any real record, often because a property it depends on got renamed or a form it watched was replaced months ago. HubSpot’s own workflow documentation covers how enrolment triggers are configured in the first place, worth re-reading against the live workflow’s actual settings rather than relying on memory, since the only reliable way to catch check 20 is reading enrolment history directly rather than trusting the on/off state in the workflow list.
Reporting: 6 Checks
| # | Check |
|---|---|
| 22 | Does the headline pipeline number in the main dashboard trace back to real, current deal records when spot-checked |
| 23 | Are closed-lost deals excluded consistently across every report that should exclude them |
| 24 | Do date-based reports use the property the business actually cares about (close date versus create date versus last activity) |
| 25 | Is there a report leadership relies on that’s actually built on a static list rather than a live filter |
| 26 | Do different dashboards showing the same metric ever disagree, and if so, why |
| 27 | Is anyone still manually exporting data to build a report HubSpot could generate live |
Check 25, a report leadership relies on that is actually built on a static list rather than a live filter, is easy to miss because the report itself looks fine right up until the list stops being refreshed and nobody notices. A static list is a snapshot frozen at the moment someone built it; a live filter re-evaluates against current data every time the report loads. The two look identical in a screenshot, which is exactly why this check has to involve opening the underlying list definition rather than trusting the report on screen.
The four-phase order above is the one every free Equanax audit follows. Equanax holds a live, checkable listing on the HubSpot Solutions Directory as a Sales Ops and RevOps Partner.
Any audit involving personal data should be run with the ICO’s guidance for organisations in mind, particularly around check 8 through check 14 above.
Related Reading
For the full implementation and ongoing administration side beyond a one-off audit, see HubSpot Consultancy. For the strategy layer above any single platform, see RevOps Consultancy. On the automation side specifically, n8n Consultancy covers what to build once the audit above is clean, HubSpot Contact Deduplication With n8n covers check 8 and 9 in depth, and HubSpot Lead Routing Automation covers what becomes possible on the routing side once the pipeline above is properly audited.
Go deeper: RevOps Automation Maturity Model · n8n vs Zapier for RevOps Automation · HubSpot Lead Routing Automation
Frequently Asked Questions
How long does a proper HubSpot audit take?
A working session on the actual portal typically runs 60 to 90 minutes for the live checks above, followed by a written summary of what’s built, what’s broken and what a fix would involve. A full remediation afterwards takes longer and depends on how many of the 27 checks turn up real issues rather than a clean bill of health.
Can I run this checklist myself, or do I need a consultant?
Most of the 27 checks are runnable by anyone with admin access and the time to sample records directly rather than trust dashboard summaries. Where it gets harder without outside help is check 20, tracing a workflow’s real enrolment history, and check 26, reconciling two dashboards that disagree, both of which usually need someone who has done this enough times to know where the discrepancy is likely hiding.
How do I tell a workflow that has stopped firing from one that’s correctly enrolling nobody?
Open the trigger’s filter criteria and run it as a saved list or view, not just checking whether the workflow itself is switched on. If that filter genuinely returns zero current records, the workflow is working correctly, it simply has nobody to enrol right now. If the filter returns records that clearly should be enrolling and are not, the trigger itself is broken, usually because a property it depends on was renamed or a form it watched was replaced.
Should I audit before or after a Salesforce to HubSpot migration?
Before, on the Salesforce side specifically, since a migration that imports years of accumulated mess by default carries every one of that mess’s problems straight into the new system. Auditing the source instance first, deciding what genuinely transfers versus what gets left behind, avoids re-running this same 27-check list on HubSpot a year later against self-inflicted damage.