# HubSpot-Salesforce integration: which system owns each field before you turn the sync on

https://salesbond.app/blog/hubspot-salesforce-integration-which-crm-owns-which-field/
Published: 2026-10-24 · Updated: 2026-10-24

Before you turn on the HubSpot-Salesforce integration, decide which system is the source of truth for each field: one system writes, the other reads. The setup steps are in [HubSpot’s installation guide](https://knowledge.hubspot.com/salesforce/install-the-hubspot-salesforce-integration); this is the decision that comes before them. HubSpot’s planning guide agrees: Salesforce can own stages and revenue while HubSpot owns marketing engagement ( [HubSpot: plan your HubSpot-Salesforce implementation](https://knowledge.hubspot.com/integrations/plan-your-hubspot-salesforce-implementation)). Skip it and the sync overwrites good data with stale data; the first sign is a deal amount or owner that keeps changing back.

## When two CRMs is a deliberate choice and when it is drift

It’s deliberate when marketing lives in HubSpot, sales lives in Salesforce, and somebody can say in one sentence what crosses the border. “Qualified leads go to Salesforce, closed revenue comes back for attribution” is such a sentence, and HubSpot’s planning page uses almost exactly that example.

Drift looks different. Sales started in HubSpot, a new VP brought Salesforce, half the reps still log calls in HubSpot and nobody turns the sync on because nobody knows what it will do. Or the sync has run for years and whoever set it up has left.

Our test: can the sales manager say, without looking, which system a rep opens to change a close date? If the answer is “either”, the integration has no owner. If the honest answer is that the team belongs on one CRM, see [the HubSpot vs Salesforce checklist for sales managers](https://salesbond.app/blog/hubspot-vs-salesforce-sales-manager-checklist/).

## Eight fields, one writer each: the owner table for a HubSpot-Salesforce integration

Start with Owner, the field people fight over most. The Owner mapping can only be two-way; which system assigns owners is a team rule, not a setting.

Everything else is a choice. The standard deal-to-opportunity mapping covers Owner, Close date, Name, Type, Description, Amount and Stage ( [HubSpot: sync Salesforce opportunities to HubSpot](https://knowledge.hubspot.com/salesforce/sync-salesforce-opportunities-to-hubspot)). Each mapping carries a sync rule; the mapping screen offers Prefer Salesforce unless blank, Always use Salesforce, Two-way and Don’t sync. Under Two-way the most recent value always overwrites the other, and a value deleted on one side is deleted on the other ( [HubSpot: map HubSpot properties to Salesforce fields](https://knowledge.hubspot.com/salesforce/map-hubspot-properties-to-salesforce-fields)).

That is the whole argument for the table. Two-way sounds fair, but it’s the rule under which a rep’s stale edit on Tuesday erases the manager’s correction from Monday, and nothing flags it.

Here is our table for reps in Salesforce and marketers in HubSpot. Your writer column can differ; every row still gets exactly one.

| Field | Writer | Reader | Sync rule | What the rule means on a conflict |
| --- | --- | --- | --- | --- |
| Deal owner | Salesforce assigns | HubSpot | Two-way; HubSpot allows no other rule for Owner | Nobody reassigns in HubSpot. A HubSpot owner with no matching active Salesforce user resets to the last Salesforce value |
| Contact owner | HubSpot at creation, Salesforce after handoff | Both | Two-way, same constraint | Owner names and emails must match exactly between systems, or the change does not land |
| Deal stage | Salesforce | HubSpot | Always use Salesforce | The HubSpot pipeline is a mirror, not a workspace |
| Amount | Salesforce | HubSpot | Always use Salesforce | Marketing reports read it and never edit it |
| Close date | Salesforce | HubSpot | Always use Salesforce | Same as Amount |
| Deal name | Salesforce | HubSpot | Prefer Salesforce unless blank | HubSpot fills a blank once, then stays quiet |
| Lifecycle stage (contact) | HubSpot up to MQL; the Salesforce opportunity stage after | HubSpot only | The lifecycle setting, not a field mapping | It never moves a contact backwards, and HubSpot’s value never changes a Salesforce record |
| Lead status | HubSpot until handoff, Salesforce after | Both | Our recommendation: a custom mapping with Prefer Salesforce unless blank | A blank in Salesforce means marketing still owns the lead |

The Owner rows follow the mapping page: only HubSpot owners that match an active Salesforce user’s name and email sync to Salesforce. The lifecycle row is a HubSpot setting, not a mapping ( [HubSpot: manage your Salesforce integration settings](https://knowledge.hubspot.com/salesforce/manage-your-salesforce-integration-settings)); more in [lifecycle stage vs deal stage sync](https://salesbond.app/blog/hubspot-lifecycle-stage-vs-deal-stage-sync/).

Lead status is our convention, not something HubSpot sets up: a custom mapping so the handoff has a field both sides can read ( [why it stays separate from lifecycle stage](https://salesbond.app/blog/hubspot-lead-status-vs-lifecycle-stage/)).

One more decision: which records cross at all. Only contacts in the inclusion segment sync from HubSpot to Salesforce, and with no segment selected every HubSpot contact syncs (same settings page). We treat the segment as the lead-status row made real.

## What happens on a conflict and how to see it

A conflict is two edits to one field in two systems inside one sync window. HubSpot checks both accounts for changes approximately every 15 minutes, and a property update is one of the sync triggers, subject to the mapping rules ( [HubSpot: import and sync Salesforce records](https://knowledge.hubspot.com/salesforce/import-salesforce-records)). Under Always use Salesforce the HubSpot edit is simply gone; under Two-way the later edit wins. Both are the rule working as designed, so no error appears. A clean sync can still be a wrong one.

![Timeline of two edits to one field: Two-way keeps the later edit, Always use Salesforce discards the HubSpot one](https://salesbond.app/wp-content/uploads/2026/10/hubspot-salesforce-integration-which-crm-owns-which-field-2.png)

There is a trap at the very first sync. A newly created mapping does not sync existing values retroactively, and when a contact has no sync history for the mapped field, the first sync takes the current Salesforce value as the baseline and can overwrite a more recent HubSpot value ( [HubSpot: map HubSpot properties to Salesforce fields](https://knowledge.hubspot.com/salesforce/map-hubspot-properties-to-salesforce-fields)). If HubSpot holds a year of fresher data in a field, move it over before you make Salesforce the writer.

Deletions are lopsided too: deleting a synced Salesforce opportunity deletes the HubSpot deal, but deleting a HubSpot deal leaves the opportunity in place ( [HubSpot: sync Salesforce opportunities to HubSpot](https://knowledge.hubspot.com/salesforce/sync-salesforce-opportunities-to-hubspot)).

The errors that do surface live in one place: Settings > Integrations > Connected Apps > Salesforce, the Data sync tab, then Sync Health. Each error type is a card with the number of current errors and impacted records; from there you can view the affected records, resync after fixing, or export a CSV ( [HubSpot: Salesforce integration API calls and sync errors](https://knowledge.hubspot.com/salesforce/resolve-salesforce-integration-sync-errors)).

## Three weekly checks: sync errors, duplicates, deals without an owner

Fifteen minutes on Monday, in this order.

Start with Sync Health. Two picklist errors matter most to a sales manager: “Inactive Salesforce owner” and “Missing or invalid opportunity stage”. Each means someone broke a row of the table: a deal went to someone who isn’t an active Salesforce user, or a stage was added on one side only.

Then duplicates. For the “Salesforce duplicate rule” error, HubSpot recommends a Salesforce admin review the matching rules before anyone resyncs. We covered [the Salesforce rules](https://salesbond.app/blog/salesforce-duplicate-rules-matching-rules-manager-check/) and [the HubSpot side of duplicates](https://salesbond.app/blog/hubspot-data-quality-command-center-duplicates/) separately.

Last, deals without an owner. Salesforce requires an owner, so when an unassigned HubSpot record creates a new Salesforce record, the owner becomes the integration user (mapping page). A list view of opportunities owned by that user is your “no owner” report. Errors are loud, so they go first. Ownerless deals are silent, and they are teh ones that cost revenue.

## Who in a small team owns the sync

Two people, two jobs. The sales manager owns the table and decides when a row changes. The HubSpot admin owns the settings that implement it: mappings, the inclusion segment, the connected user. On a five-person team that’s one person, and the table still gets written first, because a mapping edited to “fix one deal” is how a two-way rule sneaks back in.

The connected user deserves a name on the team page. Its permissions decide what HubSpot can create or update in Salesforce, and a replacement needs permissions equal to or greater than the previous user’s ( [installation guide](https://knowledge.hubspot.com/salesforce/install-the-hubspot-salesforce-integration)). If it’s a departed admin’s login, the sync is one offboarding away from stopping. And like any app that writes to deals, it goes on [the manager’s allow-list](https://salesbond.app/blog/hubspot-integrations-write-to-deals-manager-allow-list/).

## When to stop syncing and pick one system

Stop when the table can’t be filled. If sales and marketing argue for a month about who writes Amount, the problem is the operating model, and no sync rule fixes that.

Shrink when the weekly checks keep finding the same rows broken. A team that keeps reassigning owners in HubSpot is telling you where it actually works. Shrinking is cheap: deals in a pipeline that isn’t synced stay out of Salesforce, and standard mappings can’t be deleted but can be set to Don’t sync (opportunity and mapping pages above). In practice contacts keep flowing for marketing, deals stay in one place for sales, and the table shrinks to the rows a team can keep.

A disclosure, since the weekly checks are the part that lapses: we build SalesBond, a sales management layer on top of the CRM a team already uses; we started with Pipedrive. It works on top of HubSpot and Salesforce too, so the Monday look at deal data stops depending on someone remembering to open Sync Health. The table, though, still has to be written by a person. [Check your CRM with SalesBond](https://salesbond.app/) once it is.