How do you fix data quality in HubSpot?

Every record in your portal arrived through an entry point, and each entry point writes values by its own rules. Forms, imports, integrations and the people on your team all count as entry points. At launch, one team set those rules together, so they lined up. Since launch, each entry point has changed on its own schedule.

Why HubSpot data quality drifts after launch

Drift builds from small changes that nobody checks against the rest of the portal. The common ones look like this:

• A marketer adds a form with a free-text field where the old form used a dropdown.
• A sales rep imports an event list with full state names in place of 2-letter codes.
• An integration starts writing to a field that another system also writes.
• A team creates a property for one campaign and abandons it when the campaign ends.
• New staff enter records without the conventions the launch team agreed on.

No single change looks serious. Together they produce duplicate contacts, conflicting values and fields your team stops trusting. Every list, workflow and report that reads those fields inherits the problem.

Suppose your website form stores country as typed text while your billing integration writes a 2-letter code. A list filtered on one format misses every contact stored in the other. A country report splits one market into several rows, and the forecast built on it drifts with them.

Duplicates add a second problem. Two records for one person split that person’s emails, calls and deals across both. A rep who opens one record sees half the history and works from it.

This guide breaks the fix into 4 steps. Each step names its action, its owner and the check that closes it. The order matters, because each step depends on the one before it.

Step 1. Trace each problem to its source

The first action is an inventory of every entry point, matched to the problems it causes. The inventory lists each form, each recurring import, each integration and each team that enters records by hand. Next to each one, we note which fields it writes.

We run this as a diagnostic across 6 areas of the portal:

• The data model and its objects
• Properties and their values
• Workflows
• Integrations
• Reports and dashboards
• User adoption

For each problem, we sample the bad records and work backward to the entry point that wrote the value. A duplicate contact often points to an entry point that creates records without looking for an existing match. A malformed value often points to a free-text field or an import file with no format rules.

Then we rank the problems by their effect on your team. A broken field that drives lead routing ranks above an unused property with stray values. We fix the highest-impact problems first, and our portal optimization work follows that order.

Your HubSpot expert at Bryant Works owns the diagnostic. Your ops lead names an owner on your side for each entry point, such as the marketer who runs the forms. The step closes when every problem on the list has a named source and a named owner.

Step 2. Deduplicate and normalize the records

With the sources known, the cleanup moves to the records already in the portal. This step uses the deduplication, normalization and archiving we run before a CRM migration:

1. Agree on match rules. A match rule names the fields that identify one person or one company, such as email address or company domain.
2. Choose the surviving record and the winning value for each field. The newest value wins on some fields, and the source system wins on others.
3. Merge duplicates in batches. Check each batch against the approved rules before the next one runs.
4. Normalize each field to one format. State codes, country names, phone numbers and job titles each get a single standard.
5. Archive the records that should stay behind, such as test contacts and addresses that bounce.

An archive keeps old records out of your working lists while the history stays somewhere your team can reach it. Deletion removes that option. Archive first, and delete only what your team has reviewed.

Where workflows cannot do the job alone, we write custom code actions for normalization and deduplication.

Your ops lead owns the match rules and the winning-value choices, since your team knows which system holds the right data. Our expert runs the merges and the normalization. The step closes when a rerun of the duplicate scan finds no new matches. A sample of merged records must also show the values your team approved.

Step 3. Automate the checks that keep data clean

Clean records stay clean only when the entry points enforce the rules the cleanup applied. This step moves each rule out of a person’s memory and into the portal:

• Replace free-text fields with set options wherever the answer comes from a fixed list.
• Run your normalization rules on new records through workflows, with custom code actions where a workflow cannot handle a rule alone.
• Flag records that arrive with a required field missing, and route them to the entry-point owner from Step 1.
• Run each rule against test records before you switch it on.

We rank automation candidates by the time they save and the errors they remove, then build the highest-ranked first. A rule that fixes a value on every inbound lead outranks a rule that tidies a field one report uses. Our automation work follows the same ranking.

A single workflow can go live in days. An automation audit with a full build-out typically takes 3 to 6 weeks.

Our expert builds the rules. Your entry-point owners confirm that each rule matches how their team works. The step closes when a test record with a bad value gets corrected or flagged before it reaches a list or report.

Step 4. Audit integrations for silent failures

An integration that fails on one field can leave the rest of the record looking normal. Two systems that both write a field overwrite each other, and the value changes with whichever system wrote last. Neither problem shows up until a report looks wrong.

We audit your existing integrations for gaps, errors and silent failures before we build anything new. Record these facts for each connection:

• The system that owns each field it touches
• The sync direction for each object
• The path a failed record takes, and the person who sees the failure
• The volume and frequency your team needs today

Field ownership drives the fix. Each field gets one system that owns it, and the other systems read it or leave it alone. For an insurance agency that runs AMS360, we built a custom sync where some objects sync both ways and others update on triggers.

For each connection, we choose between a native connector, third-party middleware and a custom build. Data volume, sync frequency and maintenance needs decide the choice. Before go-live, we validate every data flow in a staging environment. Our integration work covers the audit and the rebuild.

Our expert owns the audit. Your system admins confirm field ownership for the tools they run. The step closes when each field has one owner in writing and a staging test shows no field overwritten by the wrong system.

What goes wrong in a data cleanup

These mistakes undo a cleanup:

• Merging on a match rule that is too loose. A match on name alone joins 2 different people into one record.
• Cleaning before closing the source. The same entry point writes the same errors again.
• Deleting where an archive would do. A record someone needs next quarter disappears.
• Changing a field’s format without checking what depends on it. Lists, workflows and reports that filter on the old values stop matching.
• Running bulk edits without a batch check. One wrong rule spreads across the whole database.
• Leaving the entry points without owners. Drift returns once the cleanup team moves on.

A cleanup cannot recover a value that no system ever captured. If no form or import collected a contact’s industry, the field stays blank until someone gathers it.

Typical timelines

Work	Typical range
Audit and cleanup of one hub	3 to 4 weeks
Enterprise portal across Marketing, Sales and Service hubs	8 to 12 weeks
Single workflow	Days
Automation audit and build-out	3 to 6 weeks
One integration with a documented API	1 to 3 weeks
Integration build across several platforms	4 to 8 weeks

The rules hold only while your team knows them. We train your team inside your portal, on your real records and pipelines, and leave recorded walk-throughs for the hires who join later.