A HubSpot enrichment workflow should create a proposed update before it changes a customer record. It must identify the exact contact or company, validate the new field, preserve the provider and time of evidence, and read the record back after the write. For uncertain identity or commercial data, it should create a review item instead of changing the CRM automatically.
Who this is for
HubSpot administrators and RevOps teams that need more complete contact and company data without damaging reporting or ownership.
Decision guide
| Decision | What good looks like | What to test |
|---|---|---|
| Identity | Choose one stable record identifier and an explicit match policy. | Email, company domain, and CRM ID can conflict; do not merge on a weak signal. |
| Field contract | Define source of truth and validation rule per property. | Contact phone, company employee count, and lifecycle stage need different rules. |
| Write policy | Allow only deterministic, evidence-backed updates. | Route conflicts, stage changes, and ownership changes to review. |
| Observability | Store a field-level receipt and monitor exceptions. | A workflow should explain why a value changed. |
Operating method
- Choose a narrow workflow, such as enriching company domain after a form submission or refreshing bounced phone data.
- Search for the existing HubSpot object before creating anything. Use a match score and record ambiguous candidates.
- Request enrichment, normalize the candidate value, and apply field-specific validation.
- Compare current and proposed values. Skip known-good values and only write an explicit improvement.
- Read the object after the write, attach the receipt, and add unresolved cases to a human queue.
Implementation details
- Normalize the input before calling a provider: lowercase domains, preserve the original record ID, and separate person and company identifiers.
- Stop the waterfall when the acceptance rule passes, not merely when a provider returns a value. Record which provider supplied the accepted result.
- Treat missing, invalid, conflicting, and provider-error results as different states. Each state needs its own retry or review rule.
- Measure cost per accepted field and coverage on a fixed holdout set. Provider response count is not a quality metric.
Common failure modes
- Creating a new contact because the primary email was missing or malformed.
- Treating property presence as accuracy.
- Letting enrichment modify lifecycle, deal stage, owner, or contractual fields.
- Dropping provider and timestamp context after the workflow completes.
Questions teams ask
Can HubSpot enrichment run automatically?
Yes for deterministic field updates with a documented identifier and validation rule. Keep uncertain data as a proposal for review.
How do we prevent bad data from overwriting good data?
Use field precedence, freshness rules, evidence requirements, and compare-before-write checks.
What belongs in a data provenance record?
Store the old value, proposed value, source, timestamp, workflow version, validation result, and CRM object ID.
How should we handle bounced data?
Mark the field's failure type, select an appropriate refresh path, and avoid rerunning unrelated providers or workflows.
Which CRM fields should never be changed without review?
Ownership, lifecycle and deal stages, contractual data, strategic account tier, and identity merges.
Methodology and sources
This guide is based on public product information and a production-workflow model: an input, a validated output, an accountable owner, a failure path, and a measurable unit cost. Recheck product and pricing claims before purchase.
Related integrations and documentation
Apollo integration · People Data Labs integration · Crustdata integration · CLI installation guide
Related guides
CRM data quality automation · B2B data enrichment waterfall · RevOps workflow automation
Start with one workflow
Take the workflow you'd least like to do by hand. Run it with examples of what good looks like. Let the agent iterate to the optimal solution.