> ## Documentation Index
> Fetch the complete documentation index at: https://deepline.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# HubSpot enrichment workflows: safe CRM write-back

> Create HubSpot enrichment workflows that validate fields, retain provenance, prevent duplicates, and protect key sales processes.

[Human guide: work with your agent →](https://deepline.com/docs/human/guides/hubspot-enrichment-workflows.md)

> [!NOTE]
>
> Resolve an existing HubSpot record, propose a field change, and verify only an
> authorized write.

A HubSpot enrichment workflow should create a proposed update before it changes a customer record. It must identify the exact contact or company and validate the new field. It must preserve the provider and evidence time. It must 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.

## Sync enriched contacts without manual exports

An automatic HubSpot sync needs a resolved contact identity, an explicit property map and a receipt for each attempted update. A provider returning a company or phone value is only the enrichment step. The sync is complete when the intended HubSpot record contains the approved value.

[HubSpot's contacts API guide](https://developers.hubspot.com/docs/api-reference/legacy/crm/objects/contacts/guide), checked September 14, 2026, documents retrieving contacts by record ID or email and updating contact properties. Inspect the current [Deepline HubSpot action](https://deepline.com/integrations/hubspot) before choosing the identifier or request format. The upstream API and a particular integration action may expose different options.

| Stage | Required evidence | Failure handling |
| - | - | - |
| Resolve | Existing HubSpot contact ID and supporting identity | Review multiple candidates. do not create a duplicate as a shortcut |
| Map | Destination property's internal name and accepted type | Reject unmapped fields and incompatible values |
| Propose | Current value, candidate value, source and observation time | Preserve protected or sales-owned fields |
| Write | Only the approved properties for the resolved ID | Record partial or ambiguous outcomes |
| Verify | Read-back values match the approved proposal | Reconcile the record before another attempt |

Keep the stable event or batch identity with the destination ID to recognize repeated work. A read-before-write check alone does not provide atomic conflict protection. If multiple systems can edit the same field, define a single writer or a supported concurrency policy.

Test an existing contact, a missing contact, a changed field, an incompatible property and a timeout after submission. Keep unresolved cases visible with a repair owner. For new trial users, use the [signup enrichment guide](https://deepline.com/docs/guides/free-trial-signup-enrichment.md). for company matching, use [domain enrichment](https://deepline.com/docs/guides/company-domain-enrichment.md).

## Operating method

1. Choose a narrow workflow, such as enriching company domain after a form submission or refreshing bounced phone data.
2. Search for the existing HubSpot object before creating anything. Use a match score and record ambiguous candidates.
3. Request enrichment, normalize the candidate value, and apply field-specific validation.
4. Compare current and proposed values. Skip known-good values and only write an explicit improvement.
5. Read the object after the write, attach the receipt, and add unresolved cases to a human queue.

## Verify this task

Inspect the exact record ID, property mapping, prior value, proposed value, and observed destination result. Preserve uncertain writes for reconciliation.

Ask your agent to explain a failed check before repeating work or expanding the scope.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.