CRM Data Enrichment for Salesforce, HubSpot and Dynamics 365

Nobody notices a CRM decaying. That is the whole problem.

A bounced email produces a notification. A missing industry field produces nothing at all. The record simply fails to match a segment, drops out of a routing rule, scores low because half the inputs are null, and sits in a list nobody works. There is no error, no alert, and no obvious moment where something went wrong. By the time anyone investigates, the usual conclusion is that the campaign underperformed or the territory is weak.

This guide covers what to enrich, how to start from whichever identifier you happen to have, and how to enrich CRM data in practice inside the three platforms most B2B teams run on: Salesforce, HubSpot and Microsoft Dynamics 365.

The three data types that matter, and what each one is for

Enrichment is not one thing. It is three distinct jobs, with different sources, different match rates and different economics. Confusing them is how teams end up buying the wrong product.

The availability column is the one people skip, and it is the one that determines whether a project succeeds. Firmographic coverage on a normal B2B list will comfortably exceed contact-level coverage, and email coverage will exceed mobile coverage, in every market. Any plan that assumes equal fill rates across all three will miss its numbers.

It also explains a pattern in how the CRMs themselves have built. Native enrichment across Salesforce, HubSpot and Dynamics leans firmographic, because firmographic data is the cheapest to source and the easiest to keep current. The fields that actually let a rep make contact are the ones left empty.

Start from what you already have

Most enrichment guides assume you are holding a clean list of names and companies. Real CRMs are messier than that. You have a form fill with nothing but a work email domain. You have an account record with a company name and no website. You have a list of profile URLs a rep pasted into a spreadsheet. You have a target account list with no people attached to it at all.

The useful question is not "how do I enrich my CRM" but "what is the strongest identifier on this record, and what can that identifier reach?" There are two answers, and they lead to two genuinely different motions.

Mode A: you know the account, not the people

Three identifiers get you here, and they are interchangeable in what they unlock:

• Website URL. The strongest of the three. A domain is unambiguous, and it is usually already sitting on the record because it came in with the form fill.
• Company name. Resolve an ambiguous name to a supported company identifier first. TargetWise company enrichment does not accept name alone; country and legal registration context matter.
• LinkedIn company URL. Unambiguous like a domain, and often what you have when the account came from prospecting rather than inbound.

Any of these returns the firmographic picture: industry, headcount, revenue band, location, domain. That alone fixes routing and scoring for the account.

The second step is what makes this mode powerful. Once the company is resolved, you select the job titles you want. Head of Finance, VP Operations, whatever your buying committee looks like. The enrichment returns the people holding those titles at that company, with verified email and mobile attached.

That turns a target account list into a working contact list without anyone opening a browser.

Native CRM products differ in supported records, data sources and discovery features. Separate account enrichment, candidate discovery, known-person enrichment and approved writeback. Both completion and discovery can improve a pipeline; neither guarantees revenue.

Getting job titles right

Title selection is where Mode A succeeds or produces noise, and the reason is that titles do not mean the same thing at different company sizes. A Head of Finance at a forty-person business is the economic buyer. The same title at a four-thousand-person business is three levels below the person who signs. Selecting on the title string alone will hand you two very different people and treat them identically.

Two habits fix most of it. Target on seniority band alongside function rather than on an exact string, so that VP, Director and Head of variations of the same role all come back rather than only the phrasing you happened to type. And let the firmographics you just retrieved inform the title you ask for, since headcount is the variable that tells you how far down the hierarchy the real buyer sits.

This is also a known soft spot in native CRM enrichment, where seniority frequently comes back unknown even when the job title populates. A title without a seniority band is hard to segment on and harder to route on.

Mode B: you know the person, not how to reach them

When the record already identifies an individual through a LinkedIn profile URL, you do not need discovery. You need completion: the email address, the mobile number, or both.

A profile URL is the strongest person-level identifier you can hold short of an email address you already have, because it maps to exactly one human being. A name-and-company pair does not. There may be three people with that name at that company, the company may trade under a different name than the one on the record, and the person may have moved on last quarter. Every one of those is a chance for the match to be confidently wrong.

We go further into that in our guide to what match rate to expect from a contact enrichment API.

Choose the fields, not the bundle

In both modes, email and mobile are priced and matched separately. Requesting both when your sequence only sends email roughly doubles the per-record cost for a field nobody will open. On twenty thousand records that is a real number, and it is avoidable by specifying fields at request time rather than defaulting to everything.

A sensible default: email at the point of capture, mobile only when a record reaches a stage where somebody is going to dial it.

Where the data has to land

Enrichment that returns perfect data and writes it to the wrong place has achieved nothing. Every CRM has its own object model, its own automation layer and its own way of rejecting values it does not like.

Enriching Salesforce

Salesforce is the most configurable CRM on the market and, for that reason, frequently the one holding the worst data. Six-figure investments in licences and admin headcount sit on top of records where half the fields are blank. Salesforce data enrichment is consequently less a nice-to-have than a prerequisite for the automation you have already paid for.

Part of that is structural. Since Data.com was retired, Salesforce has had no native way to source net-new contact data. Data Cloud is a genuinely capable product, but it is built to unify and resolve data you already hold across systems, not to go and find an email address that exists nowhere in your estate. Those are different problems, and buying the former to solve the latter is a common and expensive mistake.

The object model

Enriched data lands on three objects, and the split matters:

• Lead. Pre-conversion. Holds both person and company fields on one record, which is convenient for enrichment and awkward for everything else.
• Contact. Post-conversion person record, related to an Account.
• Account. The company. Firmographics belong here, not duplicated onto every Contact.

A recurring design error is writing firmographics onto Contact records because that is where the enrichment ran. You then hold twelve copies of a headcount figure that will need updating twelve times. Write company data to the Account and let the relationship do the work.

The constraint that breaks writes

Restricted Salesforce picklists reject values outside allowed values, and record type/dependent-field configuration may add constraints. Unrestricted picklists can accept additional values through APIs. Map provider values and inspect write errors rather than assume every picklist silently rejects unknown values.

The fix is a mapping layer between the provider's taxonomy and yours, decided before you run anything at volume. It is tedious and it is the single most common cause of an enrichment project that appears to work in testing and produces empty fields in production.

Automating it

A record-triggered Salesforce Flow must use an asynchronous path for the external callout after the original save commits. Keep enrichment pending until results are reviewed, then map and write approved values. Gate later routing explicitly and handle timeout, no-match and write errors.

Enriching HubSpot

HubSpot data enrichment is the easiest of the three to set up, and the one where the native option is most likely to be enough for part of the job and definitely not enough for the rest.

What Breeze Intelligence does and does not do

HubSpot’s current native enrichment is available on eligible paid tiers. As of its July 2026 guidance, data enrichment does not consume HubSpot Credits; Smart properties do. Contact enrichment requires an existing work email, and company enrichment requires a company domain. Review current eligibility and permissions.

It is good at what it was built for. Firmographic enrichment on company records is strong, buyer intent and form shortening are genuinely useful, and it requires no configuration because it lives inside the platform.

HubSpot’s documented contact enrichment properties include role, seniority, location and LinkedIn, but do not list newly supplied contact email or phone. Company enrichment does list company phone. Auto enrichment fills empty properties; continuous updates refresh previously enriched values and respect configured/user-edited fields. Compare the fields needed before adding another provider.

That second point is a planning constraint more than a cost one. If your enrichment volume is lumpy, and most are, you either over-buy for the peak or run out during it.

The object model

Contacts and Companies are separate objects joined by an association. Firmographics belong on the Company, contact details on the Contact. If the association does not exist, company-level enrichment has nowhere to land, so verify the association before running anything at scale rather than after.

Automating it

Workflows are the native trigger. A contact-based Workflow firing on creation, calling out to an enrichment provider through a webhook, then branching on whether a verified result came back, covers the majority of use cases. Build the branch for the no-match case at the same time as the happy path, because on any real list a meaningful share of records will not resolve.

Enriching Microsoft Dynamics 365

Dynamics is the CRM most enrichment vendors treat as an afterthought, which is odd given how much enterprise B2B runs on it. If you are on Dynamics you will find fewer turnkey integrations and more building, so it pays to understand the object model before you choose a provider.

Why Dynamics is genuinely harder

Salesforce and HubSpot orgs vary. Dynamics orgs vary more. Because Dataverse encourages deep customisation, enterprise deployments routinely add custom tables, custom columns and custom option sets, and custom columns carry a publisher prefix rather than a predictable name. A contact table in one organisation may look nothing like a contact table in another.

The practical consequence is that field mapping cannot be assumed from documentation. It has to be read from the environment. Dataverse exposes entity metadata through the Web API, so a robust integration discovers the schema at runtime rather than hardcoding field names that will be wrong in the next org.

What Microsoft ships natively

Dynamics 365 Sales AI-powered data enrichment supports Contact, Opportunity, Lead and Account records using authorised email and Teams communications. It can propose contact phone, email and job-title details from those communications. This is distinct from a promise of third-party verified mobile coverage; confirm licensing, consent, permissions and supported entities.

It is also not a contact data product. It reasons over interactions you have already had. If nobody at your company has ever emailed the person, there is no signal to reason over, and the field stays empty. Net-new contact details still come from outside.

The agentic angle

Microsoft has been opening Dynamics 365 Sales to external intelligence through the Model Context Protocol, allowing data providers to feed enrichment and firmographics directly into sales agents inside the Microsoft environment. Several established data vendors were named among the early partners.

This matters strategically. It means enrichment inside Dynamics is moving from a batch job that runs on a schedule toward something an agent calls mid-task while it works a record. TargetWise exposes an MCP server for exactly this pattern, which we walk through in how to enrich contacts inside Claude, ChatGPT and Cursor.

Automating it

Power Automate is the native orchestration layer. A flow triggered on row creation in the lead or contact table, calling an enrichment endpoint and writing the response back to Dataverse, is the Dynamics equivalent of a Salesforce Flow or a HubSpot Workflow. The request and response shape is the same in all three cases, which we cover in our guide to enriching B2B contacts with a waterfall API.

When to enrich

Almost every team builds enrichment on record creation, ships it, and considers the project done. Creation is the easiest trigger and the least sufficient one, because it does nothing for the hundred thousand records already sitting in the database.

The scheduled refresh is the trigger that separates a CRM that stays usable from one that quietly rots. It is also the one with the clearest cost control, because you choose the population rather than re-running everything.

A workable policy is to tier by how much the record matters. Records in active opportunities get re-verified most often, records in your defined target segment less often, and everything else on a long cycle or not at all. Re-verifying dormant records that nobody will contact is the fastest way to spend an enrichment budget on nothing.

Phone data deserves a shorter cycle than email, for a reason that is easy to miss: bad phone data fails silently. A dead email address bounces and tells you. A dead phone number rings out, and rings out again, and registers as a rep having a bad week rather than as a data problem. We covered how that plays out in B2B cold call connect rate in 2026.

The write policy nobody decides until it goes wrong

Before the first bulk run, one decision needs making, and it is more consequential than the choice of provider: what happens when enrichment returns a value for a field that already contains one?

There are three options and they are not equally safe.

Fill-blanks-only is the right default for a first run. Overwrite is the one that causes incidents, because a rep who confirmed a mobile number on a call last week has better data than any provider, and a blanket overwrite silently replaces it.

HubSpot is worth singling out here, because it has already made this decision for you in one direction. Its automatic enrichment fills blank properties only and will not overwrite a value set by a user or another system, while manual enrichment can overwrite if you tell it to. That is a sensible default and it is also a trap if you assume the same behaviour holds in Salesforce or Dynamics, where the write policy is entirely yours to define and nothing stops a badly configured integration from flattening rep-entered data on the first bulk run.

The shadow-field approach costs more to set up and is worth it at enterprise scale, because it lets you measure how often the provider disagrees with your existing data before you let it win. That measurement is the most honest vendor evaluation you will ever run.

Compliance: the CRM is where this gets real

Enrichment is a data protection question in a way that most sales tooling is not, because the CRM is your system of record for personal data. Adding a mobile number to a contact record is a processing activity, and it needs a lawful basis in the same way the rest of your processing does.

None of what follows is legal advice, and if you operate in Europe you should be taking your own. But four things are worth having settled before a bulk run rather than after one.

Lawful basis

Legitimate interests may apply after the relevant assessment; it does not replace channel consent rules. Business contact details can still include personal data and a business phone may be a personal handset. Review country/channel rules, lawful basis, transparency and suppression before use.

Transparency and the right to object

People whose data you enrich generally have a right to be told, and a right to object. In practice that means your privacy notice needs to disclose that you obtain contact data from third-party sources, and your first outbound contact needs a working opt-out. Neither is difficult. Both are routinely missed because the enrichment project sits with RevOps and the privacy notice sits with legal, and nobody connects the two.

Suppression has to survive enrichment

This is the failure mode specific to CRM enrichment, and it is the one that causes real damage. Someone opts out. Their record is flagged, or their email is cleared. Six months later a bulk enrichment run repopulates the field from an external source, the record re-enters a segment, and you contact a person who told you not to.

Processor relationships and records

Determine the roles in each processing relationship. A supplier may act as a processor, an independent controller, or in different roles for different operations. Use a DPA where processor terms apply, and review appropriate data-sharing terms, source disclosures and international transfers for other roles. Do not infer compliance or marketing permission from a business-data label.

Measuring whether it worked

Enrichment projects are usually reported on the wrong number. Records enriched is an activity metric, not an outcome. Four numbers actually matter.

• Field coverage. The share of your working population with the field populated at all. This is the before-and-after that justifies the spend.
• Match rate. The share of attempted records that returned a verified result, measured separately for email and mobile because they will differ.
• Bounce rate. The share of enriched emails that failed on send. This is the only real test of whether "verified" meant anything.
• Connect rate. The share of dialled numbers that reached the person. The equivalent test for phone data, and the one almost nobody instruments.

Measure all four against a control group of un-enriched records if you can. Without one, every improvement gets attributed to whatever else changed that quarter, and the enrichment budget becomes an argument rather than a calculation.

On evaluating a provider before you commit, the only method that survives contact with reality is running two hundred records from your own target segment and measuring what comes back. Published global match rates blend geographies and seniorities in a way that tells you almost nothing about your specific list. Any vendor unwilling to let you test that way is telling you something worth hearing.

What it costs

Core is $49/month, with $0.15 per returned work email and $0.25 per returned business phone deducted from that included balance; Growth is $149/month, with $0.12 per returned work email and $0.20 per returned business phone deducted from that included balance; Scale is $399/month, with $0.09 per returned work email and $0.16 per returned business phone deducted from that included balance. Free includes 20 emails and 5 business phones. Unused balance resets at renewal. Subscriptions renew monthly until cancelled; unresolved requested fields consume no usage balance. See current pricing and subscription terms.

For this workflow, use the current TargetWise plan rates and usage calculator. Paid plans renew monthly; unused balance resets at renewal.

The comparison people forget

Enrichment is usually priced against other enrichment vendors, which is the wrong benchmark. The real alternative is a person doing it by hand.

Estimate your own manual research and independent validation time. A manually researched record can be validated, and an API-returned field can remain uncertain; compare all-in cost per independently usable result.

For this workflow, use the current TargetWise plan rates and usage calculator. Paid plans renew monthly; unused balance resets at renewal.

Why the billing model changes the real number

Total cost per usable contact includes subscription fees, field/operation charges, failed-attempt charges where applicable, expiry, validation and integration effort. Charging rules differ among credit and result-based products; a low unit quote does not by itself establish the all-in rate. Core is $49/month, with $0.15 per returned work email and $0.25 per returned business phone deducted from that included balance; Growth is $149/month, with $0.12 per returned work email and $0.20 per returned business phone deducted from that included balance; Scale is $399/month, with $0.09 per returned work email and $0.16 per returned business phone deducted from that included balance. Free includes 20 emails and 5 business phones. See current plans.

Waterfall depth trades marginal coverage against cost, latency and uncertainty. Review current operation and vendor charging rules and measure usable incremental results; do not assume all credit products run shallow or that every additional source is free.

Bulk runs and real-time calls behave differently

A first-time CRM clean and an ongoing enrichment trigger are the same product used two different ways, and they have different constraints.

For list backfill, iterate supported one-record operations with bounded concurrency, budget, retries and checkpoints. An import or conversational list workflow is not proof that the public REST endpoint accepts a native batch payload.

A real-time call is latency-bound. A form-fill enrichment sits in front of routing, so the response has to arrive before assignment logic runs. Build a timeout and a fallback path, and make the fallback route the lead rather than dropping it. A lead that waits for enrichment that never arrives is worse than a lead routed on incomplete data.

A sensible order of operations

If you are starting from a database that has been neglected for a while, the sequence below avoids the usual failure modes.

1. Deduplicate first. Enriching duplicates means paying twice for the same person and then merging conflicting values afterwards. Always cheaper in that order.
2. Define the working population. Decide which records you actually sell to. Enriching everything is the most common way to overspend on a first run.
3. Map fields and picklist values. Including the mapping between the provider's taxonomy and your own. Do this before volume, not after.
4. Set the write policy. Fill blanks only, unless you have a specific reason otherwise.
5. Wire suppression in before the first run. Opt-out state in a field enrichment can read and never write, checked by every trigger.
6. Run a 200-record pilot. Measure match rate by field and by segment. This is your real coverage number.
7. Enrich companies, then people. Firmographics fix routing and scoring immediately, and resolving the account first improves person-level matching.
8. Wire up creation-time enrichment. So the problem stops growing while you fix the backlog.
9. Schedule the refresh. Tiered by record value, with a shorter cycle on phone than on email.

Steps one and two are the ones teams skip, and they are the two that determine whether the budget is spent on records anyone will ever contact.

Frequently asked questions