Connecting two systems is only part of an integration. The harder questions are which record represents the same person or account, which system owns each value and what happens when the systems disagree.
Before configuring HubSpot data sync, draw a field-level map. A single “system of record” label is rarely enough: billing may own an invoice status while HubSpot owns a sales qualification decision.
Write a mapping that explains the decision
The example below is illustrative. The actual fields, directions and conflict behavior depend on the connector and your process.
| Information | Authoritative source | Rule to agree |
|---|---|---|
| Customer identifier | Billing system | Keep a stable reference; do not match on display name alone. |
| Sales qualification | HubSpot | Protect the business decision from unrelated billing updates. |
| Company legal name | Agreed master source | Decide how corrections propagate and who reviews conflicts. |
| Support tier | Contract source | Agree when a contract change becomes effective for routing. |
Confirm what the connector supports
HubSpot’s data sync documentation describes configuration for direction, mappings, conflict resolution and record matching. Availability and mapping options vary by application and subscription. Check the actual connector before promising a particular field or association will synchronize.
A filtered sync also needs a lifecycle decision: what should happen when a record no longer meets the filter? Test that path rather than assuming the destination record disappears or stops receiving every kind of update.
Test updates, not only the first import
- Create a test record that matches the intended eligibility rules.
- Update a mapped property in each system and observe the result.
- Change the same value on both sides and validate conflict handling.
- Test a missing identifier, an existing duplicate and an invalid value.
- Change a record so that it no longer meets the filter.
- Check downstream workflows, reporting and associations after each change.
Use representative test data and an isolated environment where available. Document expected behavior before running the test, so the observed result is not mistaken for the intended design.
Own the exceptions
Every integration needs a place where failed or disputed records are reviewed. Assign the queue to a team, set a review rhythm and retain enough context to identify the source event. A retry is useful only after the underlying issue is understood.
Reconciliation should compare business facts as well as record counts. Matching company totals does not prove that the correct customers have the right contract status or owner.
Know when a standard sync is insufficient
Complex transformations, ordering requirements or unsupported relationships may need a different integration approach. Document that constraint early. Adding another workflow to compensate for a poorly understood sync can create competing writers.
For the wider design, use the integration operating model. For an actual platform move, use the migration guide.
Make the data flow explainable.
I can map identifiers, field ownership, conflicts and exception handling before implementing the agreed integration.
Explore CRM architecture →