RevOps Playbook: Bi‑Directional Sync for Contacts, Companies, Deals, and Opportunities (HubSpot ↔ Salesforce)

Q: How do we debug who overwrote a field?

Maintain LastWrittenBySystem and LastWrittenTimestamp per mapped field (or per field group). On conflict, log both contenders’ values and timestamps to a small “journal” object or property set so admins can review.

Published by Bles Software, a custom software and AI company based in Yehud-Monoson, Israel, building web apps, AI agents and API integrations for clients in Israel, the US, the UK and the EU.

Bi‑directional sync promises a living, breathing customer record across HubSpot and Salesforce. In practice, it can devolve into dueling updates, lost context, and finger‑pointing. This playbook shows how to design a conflict‑proof, auditable sync strategy for people, company, and revenue objects so marketing automation and CRM stay in lockstep without trampling each other’s truth.

The recommendations assume the official HubSpot–Salesforce integration is installed and that your Salesforce org uses standard Sales Cloud objects. You can layer additional tools (iPaaS, warehouse syncs, enrichment) as long as you define clear ownership and conflict policies. The goal: make each update predictable, traceable, and reversible.

Why Bi‑Directional Isn’t “Both Ways Everywhere”

Bi‑directional sync is not a checkbox; it’s a collection of field‑level contracts. Treat each mapped property as a mini‑API: who is allowed to write, when, under what freshness window, and what should happen if both systems change a value at the same time. Without this discipline, minor automation changes produce invisible data races.

The Sync Anatomy: CRUD + Relations

Any sync must handle four classes of change and two classes of relationships:

Create: new records originating in HubSpot (form fills, imports, enrichment) and in Salesforce (manual entry, lead capture tools, conversion).
Read: mirrored visibility so users can see authoritative fields regardless of system of origin.
Update: routine edits from users and automations, enrichment updates, and status changes.
Delete/Merge: hard deletes (rare), soft deletes/archiving, and merges (frequent for people and company objects).
One‑to‑one: Contacts ↔ Leads/Contacts; Companies ↔ Accounts.
One‑to‑many: Deals ↔ Opportunities and Contact Roles; Campaigns ↔ Campaign Members.

Each category must have an explicit owner and a fallback behavior so you can debug without guessing.

Directionality by Object

Use these default stances and override intentionally:

Contacts/Leads: bi‑directional for identity and profile fields; Salesforce wins for ownership and sales disposition; HubSpot wins for marketing classification and web analytics properties.
Companies/Accounts: bi‑directional for firmographics; Salesforce wins for ownership, territory, hierarchy; HubSpot may create new Companies based on domain but Salesforce must review.
Deals/Opportunities: Salesforce writes the source‑of‑truth for stage, amount, probability, close date. HubSpot mirrors for reporting and automation triggers.
Campaigns/Campaign Members: Salesforce is the durable ledger; HubSpot creates or references campaigns and membership with synchronous IDs.

Conflict Resolution and Freshness Windows

Define a small number of freshness windows and apply them consistently. A practical pattern:

Ownership window (Salesforce‑owned fields): 2 hours. If both systems write within two hours, Salesforce wins; otherwise latest timestamp wins.
Marketing window (HubSpot‑owned fields): 2 hours. If both change, HubSpot wins inside the window; otherwise latest timestamp wins.
Commercial window (revenue fields): Salesforce always wins unless HubSpot is explicitly configured as a proposal system; otherwise block HubSpot writes.

Log conflicts in a “sync journal” property set so admins can inspect what happened and when.

Identity and External IDs

Establish durable cross‑references:

Store Salesforce Ids (LeadId, ContactId, AccountId, OpportunityId) in dedicated HubSpot properties. Store HubSpot object IDs on Salesforce via custom fields. Protect these from casual editing.
Use email as the primary key for person creation but link to company by normalized domain when available.
For Deals/Opportunities, generate a shared external key on creation and write it to both systems. Use it to detect duplicates and to re‑parent activity if a merge occurs.

Create Policies

Inbound from HubSpot:

Contacts: create Salesforce Leads (or Contacts if you run a contact‑only model) when the HubSpot contact reaches a threshold (e.g., valid email domain + consent + MQL). Do not auto‑create for personal email domains unless your ICP truly includes them.
Companies: create Salesforce Accounts from HubSpot Companies only when a human validates the domain and naming; otherwise hold them in a review queue.
Deals: if using HubSpot Deals for early pipeline, create Salesforce Opportunities only when sales accepts the deal or a qualifying action occurs (e.g., discovery set). Mirror the external key.

Outbound from Salesforce:

Leads/Contacts created by reps or imports should create or update HubSpot Contacts immediately so nurture and behavioral tracking start right away.
Accounts should create or update HubSpot Companies when they become active in a territory or when they are part of a campaign.
Opportunities should be mirrored to HubSpot Deals for marketing attribution and lifecycle reporting.

Update Policies

Guard your most contentious fields:

Ownership (OwnerId, SDR_Owner__c, territory): Salesforce writes, HubSpot read‑only. If you route in HubSpot, use temporary fields that must be confirmed by Salesforce before final ownership changes.
Lifecycle/Status: HubSpot writes Lifecycle stage; Salesforce writes Lead Status; both mirror the other for visibility.
Enrichment: Vendor updates should land in staging properties. Promote to canonical fields via workflow only if the record is older than N days or the value is blank.

Merge and Delete Policies

Merges happen frequently and must be safe:

Person merges: when Salesforce merges Leads/Contacts, reconcile to the HubSpot primary via the integration’s remerge behavior; confirm that email, owner, lifecycle, and campaign history persist.
Company merges: choose the surviving domain and ensure HubSpot company associations re‑parent correctly; re‑run attribution rollups to avoid losing campaign membership.
Deletes: prefer soft deletes (an Archived__c flag or HubSpot inactive status). Hard deletes should be blocked from crossing systems unless intentional (e.g., legal request), in which case both systems should receive a tombstone event.

Activity and Campaign Data

Avoid activity drift by defining clear patterns:

Marketing emails, forms, and web sessions live in HubSpot; mirror summary KPIs to Salesforce on Contact and Campaign Member records.
Sales tasks, calls, and meetings live in Salesforce; display read‑only counts or last activity dates in HubSpot for segmentation.
Campaigns originate in Salesforce (for durable reporting). When HubSpot runs a program, it either creates the campaign in Salesforce first or references an existing one via external ID.

Error Handling and Observability

Instrument your sync like a product:

Maintain a daily “sync exceptions” report: rejected records, permission issues, missing required fields, failed merges. Group by root cause.
Add a Last_Synced_At and Last_Changed_At (per system) property on each object. Differences beyond a threshold indicate stale mirrors.
Keep a small “QA cohort” label for records used to test new rules; rotate the cohort monthly.

Security, Privacy, and Consent

Data privacy requirements often force directionality:

Respect global opt‑out: Salesforce must win if a contact is marked DoNotCall or Email Opt Out; HubSpot must honor immediately. Conversely, HubSpot subscription preferences should flow into Salesforce as read‑only context.
Minimize personal data flowing into HubSpot from Salesforce when not needed for marketing (e.g., billing addresses). Apply field‑level security in Salesforce and privacy controls in HubSpot.

Rollout Phases

Roll out in four stages and only promote after you hit quality gates:

Prototype: map 20–50 records in a sandbox or pilot segment; validate create/update/merge flows.
Partial Production: enable for one region or segment; monitor exceptions daily; tune conflict rules.
Full Production: enable org‑wide with dashboards and alerts; run a weeklong “hypercare.”
Maintenance: monthly governance, quarterly conflict policy review, semiannual dedupe cleanup.

Metrics That Matter

Use a short list of metrics to verify bi‑directional sync is healthy:

Conflict rate per 1,000 updates for ownership and enrichment fields.
Mirror latency (95th percentile) between systems by object.
Duplicate creation rate and merge time‑to‑resolution.
Percentage of Opportunities/Deals with shared external IDs and matching stages.

Anti‑Patterns to Avoid

Beware of these failure modes:

Allowing enrichment tools to write directly into canonical fields, creating flip‑flops with rep edits.
Creating HubSpot Deals that never map to Salesforce Opportunities (or vice versa), splitting your revenue truth.
Using ad hoc iPaaS rules that conflict with the official integration mappings, leading to double‑writes.

FAQ

Should we sync Salesforce Activities into HubSpot?

Syncing every activity clutters HubSpot without adding segmentation value. Mirror only lightweight rollups (last activity date, count of calls/meetings) or programmatically relevant events. Keep the detailed log in Salesforce where reps live.

What’s the best way to handle SDR dispositions?

Let Salesforce own dispositions as part of Lead Status. Mirror a summarized field into HubSpot for lists and scoring, but do not let HubSpot overwrite sales dispositions. If marketing needs granular context, add a read‑only “last disposition details” field in HubSpot.

Can we make campaign membership bi‑directional?

Yes, with discipline. Create campaigns in Salesforce and let HubSpot add members via external ID; Salesforce remains the ledger for statuses and influenced revenue. Avoid letting HubSpot create duplicate campaigns with similar names.

How do we debug who overwrote a field?

Maintain Last_Written_By_System and Last_Written_Timestamp per mapped field (or per field group). On conflict, log both contenders’ values and timestamps to a small “journal” object or property set so admins can review.

Should we sync every new Salesforce field into HubSpot?

No. Sync fields that influence segmentation, lead scoring, routing, or cross‑system reporting. Everything else adds noise and expands your attack surface.