The visible part of HubSpot work is usually the easy part to talk about.
A new pipeline. Better dashboards. A lifecycle-stage redesign. A marketing-to-sales handoff. An integration. A migration.
The less glamorous work happens before any of that: figuring out whether the portal can support the change without creating another layer of confusion.
Quick answer: A HubSpot CRM audit should happen before a major build, migration, or automation project. Review data quality, ownership, lifecycle logic, active workflows, reporting definitions, integrations, and permissions first. The goal is to stop old process debt from becoming part of the new design.
Why “just build it” creates rework
Most portals do not fail because the team lacks features. They fail because the existing logic is unclear.
A workflow may update a lifecycle stage that sales is also changing manually. A required property may be required in one pipeline but optional in another. A dashboard may look polished while measuring a deal stage no one uses consistently.
That works until the team grows. Then people stop trusting the system, build their own workarounds, and ask for more automation to patch the symptoms.
Before a big build, we look for the operational facts that need to be true first.
What should be reviewed before the project starts?
Data and definitions
Look at the properties that drive reporting, routing, segmentation, and automation. Are they defined? Are the values standardized? Is there a known owner for changes?
This is where an audit can quickly surface duplicates, stale values, values created by old imports, and reporting fields that no longer match the business process. If pipeline numbers are already suspect, start with the pipeline hygiene checks that expose bad deal data.
Ownership and handoffs
A CRM process breaks down when “someone” owns the next step.
Confirm how records move from marketing to sales, from sales to onboarding or service, and between teams. Review record owners, assignment rules, queues, and the manual steps nobody has written down.
The goal is not to automate every handoff. It is to make the critical ones explicit.
Workflows and integrations
Before building another workflow, audit the active ones. Identify the trigger, the records affected, the properties it changes, the dependencies, and the person who owns it.
Then check integrations. If another system can update the same field or create the same records, it belongs in the design conversation. Ignoring that is how a clean-looking workflow produces unreliable reporting six weeks later.
Permissions and governance
Permissions are not just a security setting. They shape who can correct data, change reports, alter workflows, and accidentally break a process.
Start with a review of the HubSpot security settings admins should check, then document who has super admin access and what changes require review.
The practical output of an audit
A useful audit does not hand your team a 90-page PDF and disappear.
It gives you a priority order:
1. Fix the records, definitions, or permissions that make current reporting untrustworthy.
2. Retire or repair automations that conflict with the intended process.
3. Confirm ownership and handoffs before automating them.
4. Build and test the new process against real records.
5. Give the operating team a simple governance routine so the portal does not drift back.
That is the kind of work behind a healthy HubSpot practice. Partner status is a useful milestone, but the value is in whether the work makes your next business decision easier.
If you need a clear baseline before a major HubSpot project, use the RSM Audit App to identify where to look first.