CRM, Data & Integrations

Why CRM Data Becomes Unreliable Again After a Clean-up

A clean-up repairs values, not the processes that keep writing them. How to find what is re-creating CRM data problems in HubSpot, and what to change.

Osama Tahir6 November 2026

Suppose a clean-up has been done properly. Duplicates have been merged, country values standardised, lifecycle stages corrected and records without an owner assigned. For a few weeks the reports look believable.

Then the familiar problems start to return. A sales manager finds two records for the same buyer. The country report shows “IE”, “Ireland” and “Republic of Ireland” as separate rows again. An owner corrected last month has quietly reverted to someone who left the team.

At that point someone usually asks a reasonable question: do we pay for another clean-up, buy a data-quality tool, or change something more fundamental?

That is the decision this article is about. I don’t think it can be made well until you know why the first clean-up did not last. A clean-up repairs the values that already exist. It does not, by itself, change the forms, imports, automations, integrations and people that keep writing new ones. If those stay as they were, some of the old problems are likely to return, whichever tool removed them the first time.

Why the clean-up did not last

What a clean-up changes, and what it leaves running

A clean-up is a correction made at a point in time. The processes that create and update records keep running afterwards, with the same rules, settings and habits they had before.

HubSpot’s own documentation shows the limit clearly. Its data quality tools can find and fix formatting issues, but HubSpot states that a record fixed there and later changed back to an incorrect format will not be flagged again. It adds that values arriving later through manual edits, the API, integrations, imports or migrations will typically not be flagged again either. See Use data quality tools (opens in a new tab).

That does not make the tool less useful. It means a clean-up tool repairs the current state; it is not a control on how the next value arrives.

Separate what the world changed from what the system re-created

Not every kind of deterioration is a design failure. People change jobs. Companies rebrand, merge and move. Some data goes out of date simply because the world it describes has changed, and the sensible response is planned upkeep for the fields that are worth maintaining.

Other deterioration is produced by the system itself, and a third kind persists because nobody is looking for it.

Three reasons data deteriorates after a clean-up, and what each calls for.

Why the data deteriorated	Typical signs	What it calls for
The system is re-creating the problem	The same wrong values reappear in the same fields; corrected values are overwritten	A change to how those fields are written
The world has changed	Old job titles, departed contacts, outdated company details	Planned refresh, and a decision about which fields are worth maintaining
Nobody is watching	Problems are found by sales, finance or a board report rather than by a check	An owner and a small number of measures

The three often coexist in one CRM, and I would not assume any of them is the main cause without looking: which one dominates depends on the organisation, the fields and the systems connected to them. Find out which applies to the fields that matter in your own portal before deciding what to buy or repeat.

What is re-creating the problems

Several processes writing the same field

In a typical HubSpot portal, a field that other processes rely on (lifecycle stage, contact owner, country, industry, job title) can be changed by several different things: forms, imports, workflows, connected applications, data enrichment, the API and people editing records. Each writer may be reasonable on its own. The problem appears when nobody has decided which of them should win.

A few HubSpot behaviours show how easily that happens:

Imports. An import set to update existing records writes the file’s values to the matching records. HubSpot provides a per-column option to stop an import overwriting existing data, but someone has to choose it for that import. Blank cells do not clear existing values. See Import records (opens in a new tab) and Set up your import file (opens in a new tab).
Forms. When a submission’s email address matches an existing contact, HubSpot updates that contact with the submitted details. A form that asks for country or job title is therefore also a writer for those fields. See Create and customize forms (opens in a new tab).
Data enrichment. HubSpot lets you choose, per property, whether enrichment fills empty values only, fills and overwrites existing values, or does not fill the property at all. HubSpot also notes that conversational enrichment and the “Enrich record” workflow action can overwrite properties regardless of those rules. See Manage data enrichment settings (opens in a new tab).
Integrations. Each mapped field in a connected application has a rule about which side’s value is kept. In HubSpot’s Salesforce integration, for example, the sync rules for standard objects include options that prefer or always use the Salesforce value, or keep the most recent value from either side, but none that always keeps HubSpot’s value. See Map HubSpot properties to Salesforce fields (opens in a new tab).

None of these is a fault. Each is a decision about authority, made in a different settings screen, often by a different person, sometimes years apart. When the decisions were never compared, the field ends up with several owners and no agreed precedence. I have made the same argument for lifecycle and ownership fields in Why HubSpot Lead Management Breaks as B2B Teams Grow; it applies to any field that routing, reporting or automation depends on.

The quieter causes

Three other causes are easier to miss, because they do not show up as an overwrite.

Entry design. Free text where a list was needed, or an optional field that later feeds a report, produces inconsistent values without any process doing anything wrong. HubSpot’s property validation rules help on some write paths and not others: they are enforced in the CRM interface, the mobile app, imports and forms built in the updated editor, but not in workflows, chatflows, meeting scheduling pages or forms built in the legacy editor. They do not reformat existing values, and custom regex rules require a Professional or Enterprise subscription. See Set validation rules for properties (opens in a new tab).

Matching. HubSpot deduplicates contacts by email address and companies by primary domain. A buyer who uses a different email address can end up as a second contact, but whether they do depends on settings and on what the record already holds. A form can be set to create a new contact for every unknown address, or to update the contact HubSpot already associates with that browser; a submission from an address stored as the contact’s secondary email updates that contact and replaces its primary email. Companies created through the API, including by installed third-party sync apps, are not deduplicated by domain at all. See Deduplication of records (opens in a new tab).

Meaning drift. No tool will notice that two teams use the same property for different things. That needs a written definition and someone who owns it.

An example: five data problems, five causes

To see how these combine, take as an example a B2B software company, Harbourline Analytics, that cleaned up its HubSpot data in September. By November, five data problems it had fixed were back, each for a different reason:

Country values came back in several spellings: the webinar form still used free text.
Industry values stopped matching the company’s own categories: enrichment was set to fill and overwrite, and the provider uses a different list.
Contact owner reverted on some records: a connected sales tool synchronised owners in both directions and still held the older assignments.
Duplicate companies reappeared: a connected application created them through the API.
Customer segment became unreliable: Sales used it for company size, Customer Success for contract value.

Another clean-up would have removed all five symptoms. Every cause would still have been running the next morning.

What the team should change

Agree authority for the fields that matter

Start small. Not every property needs governance. Pick the handful that drive routing, segmentation, reporting, automation or AI decisions, and for each one agree four things:

what the field means, in a sentence both teams accept;
which processes are allowed to write it;
which of them wins when they disagree;
who owns the definition and the exceptions.

A “single source of truth” usually works field by field rather than platform by platform. The finance system may be the right authority for billing country, the CRM for contact owner and the product database for plan tier. What matters is that the choice is explicit, written down and reflected in the settings of every writer.

Choose a control for each write path

Once authority is agreed, each writer needs a control that matches it. The simplest change is often the most effective.

One control for each way a consequential field can be written.

Write path	Simplest change	HubSpot control to check	Limit to keep in mind
Forms	Replace free text with options; stop collecting fields you already hold	Property validation rules	Not enforced on forms built in the legacy editor
Imports	Map only the columns you mean to update	The per-column option to avoid overwriting existing data	Chosen per import; blank cells do not clear values
Workflows	Agree which workflows may change each consequential field, and which takes precedence	Review which workflows edit the property	Validation rules do not apply to workflows
Data enrichment	Fill empty values only for fields you maintain yourself	The per-property overwrite rule	The “Enrich record” action and conversational enrichment can override it
Integrations	Decide the direction for each mapped field	Sync rules or field mappings	Options vary by integration; some never let HubSpot’s value win
People editing records	Fewer people able to change consequential fields	Property edit restrictions	Enterprise only, and they apply to users in HubSpot, not to the API

Several controls in the third column depend on subscription. Property edit restrictions are Enterprise only, and HubSpot advises against relying on them as a security measure (see Restrict access to properties (opens in a new tab)); workflows require Professional or Enterprise. The second column matters more: removing a writer that should not be there, changing a field type or agreeing which process takes precedence does not depend on edition.

Diagnose the next relapse from the record itself

When a field goes wrong again, start with its property history. HubSpot shows each previous value, when it changed and the source of the change, such as an import, a workflow, an integration, a form or a named user. Its list of change sources runs to dozens of types. See View a record’s property history (opens in a new tab) and HubSpot’s change sources (opens in a new tab).

That narrows the search without always explaining the cause. A source tells you which kind of process wrote the value, and often which one. It does not tell you why that process was allowed to, or which agreed rule it broke. HubSpot’s account audit log will not fill the gap either: HubSpot states that it records only actions taken by HubSpot users, and gives form submissions as an example of changes that do not appear. Changes made by automation or connected systems should not be expected there either. See View and export account activity history (opens in a new tab).

A practical method is to take one field that relapsed, read the history of a handful of affected records, list every source that wrote to it, and compare that list with the writers you agreed. The gap between the two lists is where the work is.

Know what a restore can and cannot be relied on to do

When a bad import, workflow or integration is caught quickly, HubSpot’s Restore CRM changes (opens in a new tab) can help. It rolls records back to their state at a chosen point up to 14 days earlier. A Super Admin picks the source (manual changes, a named import, a named integration or a named workflow), the object types to include and the point in time, then reviews a preview before anything changes. It covers far more than contacts: companies, deals, tickets, custom objects and several other object types are supported. A restore can return modified property values, or move records created after that point to the recycle bin; each restore handles one of those at a time. Deleted records are recovered separately, from the recycle bin or by import. It needs a Starter, Professional or Enterprise subscription to one of HubSpot’s hubs, or Smart CRM Professional or Enterprise.

The documentation describes what happens to the records. It does not describe what happens to anything the wrong values had already set in motion, such as workflows that were triggered, tasks that were created, notifications or emails that were sent, or reports produced while the wrong values were in place. Some of those may be unaffected or recoverable; the documentation does not say. Before relying on a restore as your recovery plan, check what recovery would actually need to cover in your portal.

Correcting a value is not the same as recovering what followed from it, whichever process made the change. I discuss this for AI-originated changes in When AI Makes a Recommendation, What Should Your Revenue System Do?, in the section on what happens when the process is wrong.

Give the fields an owner and measure relapse

A clean-up ends; ownership does not. Each set of consequential fields needs a named person who maintains the definition, approves new writers and looks at the measures.

The measures can be modest. Depending on the field, they might include the share of records whose value falls outside the agreed format, the number of changes made by sources outside the agreed writers, and the time between a relapse starting and someone noticing it. Define the population and the time window before using them. These are suggestions for an internal check, not industry benchmarks, and a falling number is evidence that a control is working, not proof that the data is correct.

The decision to make

Return to the original question.

Another clean-up is reasonable when the causes have been addressed, or when the deterioration is mostly the world changing and the fields are worth maintaining.

A tool helps when you already know which fields to watch, what counts as wrong and who will act on what it finds. Without those, it tends to produce a longer list of issues rather than fewer.

A design change is needed when the same fields keep relapsing from the same sources. That usually means agreeing authority and precedence, changing a few settings and often removing a writer that should not be there.

A short test will tell you which you are facing. Take one field that has gone wrong again since the last clean-up and ask four questions: which processes write it, which of them should win, who owns its definition, and how you would know if it relapsed tomorrow. If those questions do not have answers yet, the next clean-up will probably need repeating too.

MarOps Lab works on CRM architecture, data and the automation connected to them. Sometimes that means a bounded change to a few settings; sometimes it means agreeing who owns a field before anything is built. Explore revenue systems work.

Product documentation and further reading

These are primary HubSpot sources used to verify product-specific statements. Features, subscription requirements and interfaces change; check the relevant portal before implementation.