.png){kind=small}
Real-time CRM sync, explained without the marketing layer
Most 'real-time' CRM integrations are batch jobs with a shorter cron. This is what real bidirectional sync looks like at the engine level — and why it matters when sales is staring at the dashboard.
- Author
- Ruben Burdin · Founder & CEO
- Published
- June 3, 2026
- Read time
- 9 min
What 'real-time' actually means in production
Most CRM integrations sold as "real-time" are a 5-minute batch with a marketing veneer. The mechanism underneath is the same one that's been wrong for fifteen years: poll, diff, push. Each pass loses ordering, drops fields that were unset, and re-emits updates already applied — because the system has no concept of a change event, only of an end-state delta.
Real-time means three things at once. First, the source emits a change as it happens — not on an interval. Second, the change is propagated as a discrete event with identity, not as part of a recomputed snapshot. Third, downstream consumers can ask the engine to replay events in the same order in which they originally fired.
Two-way sync is not mirroring
Two-way sync gets sold as if it were a database trigger that goes both ways. It isn't. A real bidirectional sync layer keeps a per-object ledger of which side last wrote each field, then applies conflict-resolution rules at the field level. Mirror semantics — where every write on one side blindly overwrites the other — produce a feedback loop within minutes.
- Field-level ownership:
emailis HubSpot-owned,account_owneris Salesforce-owned. - Last-writer-wins by timestamp, with a clock skew tolerance.
- Explicit reconciliation on conflict, surfaced as a replayable event.
If a vendor can't answer "who wins when both sides write the same field within 200 ms?" — they aren't doing two-way sync. They're doing one-way mirroring twice.
Change data capture across Salesforce and HubSpot
Salesforce exposes change events through Platform Events and the Streaming API. HubSpot exposes them through webhooks tied to object subscriptions. Both have ordering guarantees inside their own surface but neither commits to global order across object types.
A real CDC pipeline ingests both streams, attaches a monotonic sequence at the engine, and writes them to a queue you can rewind. When a downstream system fails for an hour, you don't lose anything — you replay from the last committed offset on the consumer side.
FAQ
Frequently asked questions
