HubSpot + Salesforce integration

Nobody sets out to run two CRMs. They end up with two because sales bought one and marketing bought the other, because an acquisition arrived with its own, or because a migration that was meant to take a quarter is in month nine. The question on this page is almost never whether the two can talk, since HubSpot builds the connector itself. It is who owns which record, and what happens when both sides edit the same field.

The common shape is a division of labour. Salesforce stays the system of record for accounts, opportunities and anything finance reports on. HubSpot owns marketing: the forms, the emails, the scoring, the attribution. The sync keeps the two views of a person in agreement and leaves everything else alone. We are implementing this pattern now for an education publisher on a 16-week onboarding: Salesforce stays the sales system of record, HubSpot takes marketing, and the native sync carries the core objects.

The second shape is a migration with a long tail. Everything moves eventually, but not on one weekend, so the sync is a bridge with an end date rather than a permanent fixture. Naming that end date changes the decisions: a bridge can carry less, break more visibly and cost less to build than a marriage.

What makes either shape fail is unowned fields. Where both systems write the same property, the two integrations take turns overwriting each other and a salesperson watches their edit disappear twice a day. That is a governance problem wearing a technical costume, and it is settled in discovery.

Seven objects cover almost every engagement. Leads and contacts both land on HubSpot contacts, which is the first real decision, because a lead in Salesforce is a pre-qualification record and HubSpot has no separate object for it. Accounts become companies, opportunities become deals, cases become tickets, tasks and events become activities, and custom objects map across on Enterprise subscriptions.

Everything keys on the Salesforce record identifier, kept in a HubSpot property, with email used only as a fallback for a contact that has never synced. That identifier is what makes the sync repeatable and what lets a migration reconcile afterwards.

Two mappings deserve more thought than they usually get. Record types to pipelines, because a Salesforce org with five opportunity record types does not want five HubSpot pipelines by default. And stage names, which are resolved by label, so renaming a stage on either side quietly breaks the mapping until somebody updates it.

The native integration is a polling sync with rules on both ends. HubSpot checks Salesforce roughly every 15 minutes, applies the selective sync filters to decide what comes in, and applies the inclusion segment to decide what goes out. There is no queue for you to run and no state for you to hold.

A custom addition sits beside it rather than replacing it. It reads Salesforce on a watermark, using the changed-records resource that reports what moved within a timespan, which the API documents as reading the record’s system modified timestamp and covering no more than 30 days with a cap of 600,000 identifiers per call. Where events have to be quicker, Salesforce publishes change events that a subscriber can replay from a stored position, with 72 hours of retention.

The custom side keeps its own watermark, its own dead letter table and its own replay endpoint, so the two mechanisms can be reasoned about separately when something looks wrong.

The native integration is the default, and the burden of proof sits with anything else. It carries the standard objects both ways, it is maintained by HubSpot, and the configuration is a settings screen rather than a deployment, which is 8 to 24 hours of mapping and rule setting rather than a build.

Custom work joins it in a few specific situations. Custom objects matter to the business but the subscription tier does not allow the native custom object sync. The rule that decides which records move cannot be expressed as a filter or a segment. Or the project is a migration, where one reconciled pass with a written mapping beats a permanent sync nobody will turn off.

A per-task automation platform is the route we advise against here. Two CRMs generate record changes continuously, and paying per task for that traffic scales with the size of the database rather than with the value of the sync.

1. Scope. We inventory the objects, the record types, the field counts and the current API consumption, then agree who owns what.
2. Architect. The mapping sheet, the precedence rules, the inclusion and selective sync design, and an explicit decision about how long coexistence lasts.
3. Build. The native integration configured in a Salesforce sandbox connected to a HubSpot sandbox portal, plus any custom service beside it.
4. Validate. A sample migration, a reconciliation by count and by spot check, and a deliberate test of the conflict rules.
5. Operate. The sync health view watched weekly, with a standing review of records that fail to sync rather than a dashboard nobody opens.