How to Audit an Existing HubSpot CRM Setup
TL;DR: Auditing an existing HubSpot CRM setup is a different job to building one from scratch. Before you touch anything, reconstruct what the original configurator was trying to achieve - then use workflow history logs and enrolment data to establish what's actually firing. The most common failure mode is deactivating something that looks redundant but is holding a live sequence together. A completed audit should produce three things: a current-state map, a severity-ranked findings log, and a sequenced remediation roadmap.
How to audit an existing HubSpot CRM setup: where to start?
Start with the intent behind the configuration, not the configuration itself. Every workflow name, pipeline stage label, and property description is evidence of a decision someone made - and you cannot safely change a decision you do not understand. Reconstruct what the original configurator was trying to build before you form any opinion about what needs fixing.
Most audit guides open with a checklist. The checklist is the wrong starting point when you have inherited someone else's configuration, because every naming convention, pipeline stage, and enrolment trigger was a decision. Read the portal as a primary source before you open a single workflow or delete a single property. A pipeline stage called "Awaiting PO" tells you the original motion was enterprise B2B procurement. A contact property called "Nurture Track Override" tells you someone ran into a problem and patched it. A workflow named "TEMP - Do Not Delete" tells you someone was afraid to touch it and left. These are clues, not noise.
When there is no documentation - which is the common case - pull the workflow creation date, the creator name, and the enrolment history. Cross-reference with any HubSpot notes, deal activity logs, or email sequences that reference the same contacts. You are reconstructing intent from behaviour, not from a spec document, and that reconstruction has to happen before any remediation starts.
The specific failure mode I have seen repeatedly is this: a workflow looks redundant because it has low enrolment numbers. You deactivate it. Three weeks later, someone flags that deals are no longer progressing past a certain pipeline stage. The deactivated workflow was not a standalone automation - it was firing on a property set by step two of a parent workflow, and that parent workflow enrolled contacts at the top of a nurture sequence. The parent had healthy enrolment numbers. The deactivated one fired maybe four times a month. Turning it off broke the sequence for every contact who reached that point after the deletion date. Nothing errored. Nothing alerted. The pipeline data just quietly degraded.
The distinction between "this looks unused" and "this is unused" is not semantic. Low enrolment does not mean no enrolment, and a workflow that fires once a month on a specific trigger condition may be doing exactly the work it was designed to do. Treat every active workflow as load-bearing until you can prove otherwise from the enrolment history.
How do you identify which workflows are actually firing?
HubSpot's workflow list view shows names, statuses, and enrolment counts - none of which tell you whether an automation is doing its intended job, conflicting with another workflow on the same trigger, or firing in the wrong sequence because of stacked timing delays. Reliable answers come from the history logs and per-contact enrolment data, not the list.
The method I use is to open a sample of recently enrolled contacts - typically ten to fifteen - and trace their enrolment history across all workflows. You are looking for the sequence of what fired, in what order, at what time. HubSpot shows this on the contact record under "Activity", but you need to filter for workflow enrolments specifically and look at the timestamps. This is the only reliable way to establish actual behaviour rather than intended behaviour. The list view is an index. The contact record is the evidence.
Two workflows both setting lifecycle stage on the same trigger condition is a common problem in inherited portals. The downstream effect is non-deterministic - whichever workflow processes last wins, and which one that is depends on queue timing at the moment of enrolment. In practice, you see lifecycle stage flickering on contacts that should have a clean linear progression, or you see contacts sitting at a stage they should have moved past. Identify these by filtering for all workflows with a lifecycle stage set action and mapping their trigger conditions side by side. If two workflows share a trigger and both set the same property, one of them is redundant at best and causing silent data corruption at worst.
Timing delay stacking is worth checking separately. A workflow with a 1-day delay feeding into a second workflow with a 3-day delay feeding into a third is not inherently wrong, but a cumulative delay of four-plus days is often unintentional. The original configurator may have been testing and never cleaned up intermediate workflows. Check whether the delay is load-bearing - does it align with a sales process step or an onboarding window? - or accidental. If you cannot find a business reason for the delay structure, flag it as a candidate for consolidation.
Worth flagging: HubSpot does not surface workflow enrolment failures prominently. A workflow set to re-enrol contacts can accumulate error states that never appear anywhere obvious in the UI. Check the "Enrolment history" tab on individual workflows for contacts marked as failed, not just the total enrolment count. A workflow showing 847 enrolments with 63 failures is a different situation to one showing 847 enrolments with 0 failures, and the list view will not show you that distinction.
When I need to safely deprecate a workflow, my approach is to turn it off, write the date, my name, and the rationale in the workflow description field, and set a calendar reminder to review in 30 days. After 30 days with no complaints and no anomalies in pipeline or lifecycle data, I delete it. Do not skip the 30-day window because you are confident. The failure mode of acting too quickly is exactly the one described above, and it is much harder to recover from than the minor inconvenience of waiting a month.
Property audit: beyond 'delete unused properties'
"Delete unused properties" is the standard advice, and it is incomplete. A property can appear unused - no form placements, no workflow references visible in the UI, no views - while still being written to by an integration or API call that runs entirely outside HubSpot. Deleting it breaks a sync you cannot see from the properties interface.
The way to identify properties written to by integrations is to check the HubSpot integration activity logs and, if you have access to any connected middleware, search the property name there. An n8n workflow, a Zapier zap, or a custom API script may be writing values to a HubSpot contact property that does not appear in any workflow or form because the integration writes directly to the contact record via the API. The property looks orphaned. It is not. I have encountered this with Bullhorn syncs specifically - a property used to store the candidate's last placement date, written by the integration, with no HubSpot-native workflow referencing it because the data was consumed by a reporting tool pulling directly from HubSpot's API. Deleting it would have broken the report and the sync simultaneously, with no immediate error to trace it back to.
Field type mismatches are a specific and common problem that compounds over time. A single-line text field being used to store what should be a dropdown value produces free-text variation: "Enterprise", "enterprise ", "Enterprise account", "ENT" - all entered by different users at different times with no validation. Any report filtering on that property is meaningless, because each value is a separate string. Identify these by exporting a sample of values for suspect properties and looking for variation that should not exist. The fix is not just adding a dropdown property - it requires a data migration of existing values before the new field type produces clean reporting. That migration needs to be in the remediation roadmap with an effort estimate attached.
Sync conflicts are the other failure mode to watch for in properties. A two-way sync between HubSpot and another CRM will have a conflict resolution rule, and in most inherited portals that rule was set during the original implementation and never reviewed. Find out which system wins on conflict for each synced property. If HubSpot-native data is being silently overwritten by a stale value from the integration, you will see it as unexplained reversions in the property history on individual contact records. The property history is one of the most useful diagnostic tools in an inherited audit - it shows every write, the source, and the timestamp.
Properties used as workarounds are a separate category and should be flagged separately. A property called "Relationship Type Override" or "Pipeline Hack Flag" is a signal that the data model itself is inadequate, not just the property set. These are not candidates for deletion - they are candidates for proper data modelling, which belongs in the architecture section of your findings rather than the property cleanup list.
The naming convention problem compounds quickly. "Lead Source", "lead_source", and "Original Lead Source" co-existing in the same portal is a concrete example: each may have been created at a different time by a different person with a different intention, and reports built on each of them produce different numbers for the same underlying question. Map which property is being used in which reports and forms before deciding which to keep. Renaming a field does not fix the data in it, and retiring a field without migrating its values destroys historical reporting.
Data architecture: the layer most audits ignore entirely
Most HubSpot audits treat data architecture as someone else's problem. They review workflows, properties, and pipelines - and miss the layer underneath all of them: whether the contact-company-deal association model actually reflects how the business operates, and whether custom object relationships and association labels are coherent enough to support the reporting the business thinks it is getting.
If custom objects exist in the portal, map them before touching anything else. A custom object with no associations, or with associations to the wrong object type, is often a sign of an incomplete implementation - someone set up the object during a proof of concept and did not finish the configuration. Do not assume it is unused. Check the property history on a sample of records and look for API writes. An object that looks empty in the UI can be receiving writes from an integration that the UI is not surfacing.
The contact-company association problem is one of the most common inherited errors in both recruitment and B2B sales portals, and it compounds quickly. In a B2B sales setup, a contact may have been associated to a holding company rather than the trading entity, which breaks any report that joins deal data to company firmographics. The revenue figures look right at the deal level and wrong at the company level, and stakeholders lose confidence in CRM reporting without understanding why. Map the extent of the misassociation before proposing a fix - bulk reassignment without a clear rule creates new errors faster than it resolves old ones.
Before making any changes to the data model, draw it out. Contact, Company, Deal, any custom objects, their relationships, their key properties, and which integrations write to which objects. This does not need to be a formal diagram - a working document is fine - but it needs to exist before remediation starts. The data model map is the baseline against which every future change is measured. Without it, you are making changes to a system you have not fully described, and six months later when something breaks, there is no reference point for what the pre-change state looked like.
The architecture layer is also where you catch the naming convention problem in its full form. Three properties with similar names is a data quality issue. Three properties with similar names, each being written to by a different source, each appearing in different reports, each producing different figures for the same question - that is an architecture problem, and it requires a naming convention decision followed by a migration plan, not just a field rename.
How do you prioritise what to fix first?
Triage findings into three tiers based on business impact, not ease of fix. Tier one is anything actively corrupting data or breaking a live process - fix it immediately. Tier two is anything producing reporting inaccuracies - fix it before the next decision that depends on that data. Tier three is anything untidy but not measurably harmful - schedule it or leave it depending on resource.
An audit that produces a flat list of 58 findings is not an actionable audit - it is a catalogue. Stakeholders confronted with an undifferentiated list will either ask you to fix everything at once, which is not possible, or defer the whole thing until they have time to process it, which means indefinitely. Severity-and-impact triage converts findings into a decision.
A concrete example of how this should work in practice: a workflow silently failing to set lifecycle stage on inbound leads is tier one. Every lead that enters the portal without a lifecycle stage is invisible to lifecycle-based reports and may not be receiving the right follow-up automation. The cost of leaving it unfixed accumulates with every new lead. A contact property with a misleading label is tier three. The property fix takes twenty minutes. The workflow fix may take most of a day. The workflow is still higher priority, because the damage is compounding in real time.
Within tier one, fix findings in order of downstream blast radius rather than in order of how visible they are. A broken enrolment trigger affecting 15 contacts per day causes more compounding damage than a duplicate property affecting a static historical dataset. The blast radius is the relevant variable.
When presenting tier one findings to a non-technical stakeholder, frame them as operational risk rather than technical debt. "We have a workflow that is supposed to set every inbound lead to Marketing Qualified Lead status. It has not been doing that for an unknown period of time, which means your lifecycle stage reports are inaccurate and some leads may not have received automated follow-up" gets sign-off on remediation. "The lifecycle stage enrolment trigger has a logical error" does not. The technical description is accurate; it is just not the framing that connects the finding to something the stakeholder cares about.
The political dimension of auditing someone else's work
When the original HubSpot configuration was built by a RevOps hire who has since left, the audit is purely technical. When it was built by a sales director who still works there, the audit findings carry weight beyond the portal. Framing matters, and getting it wrong stalls remediation before it starts.
The framing that works in practice is: "the setup made sense at the time but the business has grown past it." This is almost always accurate. Most inherited configurations were coherent at the point of implementation - they just were not designed to scale, or they were designed for a sales motion the business has since changed. Treating the original work as appropriate-for-then rather than wrong is both honest and politically navigable. It gives the current stakeholder a way to support remediation without implicitly endorsing a criticism of past decisions.
When a current team member has emotional ownership of the configuration - a sales director who built the pipeline stages, a marketing manager who designed the nurture sequences - the practical fix is to involve them in the archaeology phase. Not to be diplomatic, but because they are often the only source of the original intent. A pipeline stage called "Warm - Not Ready" means something specific to the person who created it, and finding out what that is before proposing to merge it with "Nurture - Long Term" will save you from making a change that removes a distinction the sales team actually uses. Bringing them in as context-providers rather than presenting findings to them cold changes the dynamic from criticism to collaboration.
The most common reason an audit produces no remediation is not budget or time. It is that someone with sign-off authority feels that acting on the findings implicitly validates a criticism of past decisions. I try to name this dynamic early, privately, to the person commissioning the audit - not in the findings document, and not in a group setting. That conversation is more effective than trying to design around the political layer in the way the findings are written.
The technical work of the audit is wasted if the findings document sits in a shared drive unacted on. The political layer is the delivery mechanism for the technical work, and treating it as a soft-skills afterthought is a project risk in the same category as a broken workflow or a corrupted data model.
What should a completed audit produce?
A HubSpot CRM audit should deliver three outputs: a documented current-state map of the portal covering data model, active workflows, integrations, and pipeline configuration; a severity-ranked findings log with a recommended fix and effort estimate for each item; and a prioritised remediation roadmap with clear sequencing. All three are necessary - the map without the roadmap is just documentation, and the roadmap without the map has no baseline to work from.
The current-state map matters even for findings you are not acting on immediately. It is the baseline. Six months after the audit, when someone makes a change that breaks something, the current-state map is how you establish what the pre-change state was. Without it, every future change happens without a reference point, and diagnosing problems becomes a matter of guesswork rather than comparison.
The findings log needs to be specific. A finding that says "review workflows" is not a finding. A finding that says "Workflow: Inbound Lead - Set Lifecycle Stage is not enrolling contacts submitted via the Contact Us form because the trigger filter references a form submission property that was renamed in March and is no longer populated" is a finding. Each entry should contain the finding itself stated precisely, the severity tier, the recommended fix, the estimated effort in hours or days, and any dependencies - meaning which fixes must happen before this one is addressable.
The remediation roadmap needs to be sequenced, not just prioritised. A prioritised list implies any item can be addressed in any order. A sequenced roadmap accounts for dependencies: you cannot fix the lifecycle stage reporting until the enrolment trigger is fixed, and you cannot fix the enrolment trigger until you have confirmed which form submission property is currently being populated. Those dependencies need to be visible in the roadmap, not buried in the findings log.
The way I structure audit output is a working document covering the current-state map, a findings log in a straightforward format with severity tiers and effort estimates per item, and a roadmap call to walk through sequencing with the relevant stakeholders. The document is designed to be handed to whoever does the remediation work - whether that is me continuing the engagement or an internal team taking it forward. The audit output should be useful without me in the room to explain it.
If you have inherited a HubSpot portal and want a structured audit rather than an afternoon of guessing, that is the starting point for most of the HubSpot work I take on. You can book an audit session at stacklogic.co.uk/services/hubspot.
