Two-Way CRM Sync Conflicts: Field Ownership, Stale Updates, and Recovery
TL;DR: Bidirectional CRM sync is safe only when every field has an authoritative owner, every write carries source and version context, retries are idempotent, and ambiguous updates enter a review queue. Treat compliance and customer state as high-priority controls. Practice recovery on reversible records before allowing broad two-way writes.
What is bidirectional CRM sync, and why does it matter for outbound?
Bidirectional sync allows changes to move from the CRM to an outbound system and from the outbound system back to the CRM. This matters because ownership, eligibility, enrichment, sequence state, replies, meetings, and opportunities can change while a workflow is running. A late or duplicate update can route work to the wrong seller, overwrite a newer value, or reintroduce a contact that should remain suppressed.
Two-way transport is not permission for both systems to edit every field. Define authority field by field, state by state, and operation by operation. If authority is unknown, the safe result is a conflict record, not a last-write-wins overwrite.
| Field or state | Authoritative owner | Allowed inbound use | Allowed write-back | Freshness or version rule | Conflict action |
|---|---|---|---|---|---|
| Account owner and territory | CRM | Route research and tasks | No external owner overwrite unless an approved reassignment operation exists | Require current CRM record version or compare server-side update marker | Reject stale write and queue disputed ownership |
| Lifecycle, customer, and opportunity state | CRM | Control enrollment and suppression | Outbound system may append outcome context, not replace the state | Re-read immediately before enrollment and send | CRM state stops or reroutes the motion |
| Opt-out, suppression, and compliance state | Designated compliance authority | Block applicable sends in every tool | Propagate the most restrictive valid state | No relaxation from an older or lower-authority update | Stop sends, alert owner, and preserve the event trail |
| Contact enrichment field | Field-level policy | Use value plus source and observed time | Write value, source, method, and observation timestamp | Accept only permitted, newer evidence under the field policy | Keep prior value and send ambiguity to review |
| Signal event | Signal or event system | Qualify and prioritize workflows | Append normalized event with stable source event ID | Deduplicate by source event ID and event type | Return prior result for duplicates |
| Sequence enrollment and step | Sales engagement system | Display current execution state | Write normalized enrollment, step, pause, reply, and completion summaries | Use sequence event version or monotonically ordered event time | Do not replay completed steps |
| Reply, meeting, and task outcome | Conversation or task owner | Stop automation and advance workflow | Append normalized outcome with source system and owner | Deduplicate by stable conversation or event identifier | Merge only under explicit event rules; never overwrite history |
| Calculated score or derived field | System that defines the calculation | Use for routing only within its documented scope | Write the current score plus model or rule version if policy allows | Recompute in owner; do not compare unrelated versions | Reject cross-system recalculation |
Model every write as an operation
A useful write envelope contains: operation ID, entity ID, field or event type, prior version observed, proposed value, source system, source event ID, observed time, ingestion time, policy version, actor, and correlation ID. The receiver returns one of five outcomes: applied, duplicate, stale, rejected by policy, or queued for review.
- Operation ID: stable across retries of the same intended change.
- Prior version observed: the record version the writer used when making the decision.
- Source event ID: stable identifier for the underlying reply, meeting, signal, or workflow event.
- Policy version: the ownership and conflict rules used for the decision.
- Correlation ID: connects the inbound event, evaluation, write, retry, and final result.
Reject stale writes before they overwrite truth
A stale write occurs when a process proposes a change based on an older record state. Prefer server-side record versions or compare-and-set behavior where the platform supports it. If only timestamps are available, compare authoritative server timestamps, not client clocks, and route ambiguous orderings to review.
The general retry pattern in Making retries safe with idempotent APIs uses a stable identifier so repeated requests do not repeat the business action. Store the first terminal result for an operation ID and return that result on subsequent deliveries. Do this for applied, rejected, and no-action decisions.
Deduplicate events without deleting history
- Deduplicate a reply or meeting by stable event ID, not by matching text or timestamps alone.
- Keep append-only history for events. Do not collapse multiple valid events into one "latest" field.
- Separate the event from the derived current state. A sequence can have many step events but one current execution state.
- Record the duplicate decision so operators can distinguish a harmless retry from missing processing.
- Never use deduplication to erase a conflicting human edit; send the conflict to the appropriate owner.
Use a conflict and recovery runbook
| Incident | Immediate containment | Evidence to capture | Repair | Replay rule | Exit check |
|---|---|---|---|---|---|
| Stale owner or lifecycle overwrite | Pause writes for the affected field and segment | Operation ID, prior version, source, old value, new value, and impacted records | Restore authoritative CRM values and correct version checks | Replay only rejected operations that remain eligible after a fresh read | No stale write applies in the test set |
| Duplicate tasks, replies, or enrollments | Disable the downstream create action, keep event intake running | Source event IDs, operation IDs, retry count, and created object IDs | Fix idempotency key scope and remove or close duplicates through an approved process | Replay from the first uncommitted event, not the entire queue | One intended event produces one business action |
| Suppression failed to propagate | Stop applicable sends in every system | Suppression source, timestamps, delivery status, and scheduled sends | Restore the restrictive state and fix propagation path | Do not replay outreach events created during the unsafe interval | All sending systems confirm the controlling suppression state |
| Mapping change corrupted values | Freeze the affected mapping and preserve raw payloads | Old and new mapping versions, raw values, transformed values, and record IDs | Rollback the mapping or deploy a corrected version on quarantined records | Replay only payloads that can be transformed deterministically | Sampled values match the authoritative source and schema |
| Retry queue grows or poison event blocks processing | Isolate the failing operation and continue safe independent work | Error class, attempt count, payload hash, dependency response, and queue age | Fix transient dependency or route terminal failure to a dead-letter review path | Use bounded retry with backoff; manual approval for non-idempotent operations | Queue drains without repeating completed actions |
| Unknown writer or missing audit trail | Disable writes to the affected field | Available logs, API actor, timestamps, and before/after values | Restore authority and require actor, source, and correlation metadata | No automatic replay until causality is established | Every new write is attributable and reproducible |
Design retry queues for recovery, not concealment
Classify failures before retrying. Transient transport failures may retry with bounded backoff. Policy rejections and stale-version conflicts are terminal until the record is re-read or a person approves a new operation. Invalid mappings and missing authority are not transient; sending them through an endless retry loop only delays discovery.
- Pending: eligible for a bounded retry.
- Applied: committed, with result stored under operation ID.
- Duplicate: prior terminal result returned.
- Stale: fresh read required before a new operation can be created.
- Policy rejected: no retry until policy or input changes.
- Review queue: ownership, mapping, or causality is ambiguous.
- Dead-letter review: repeated technical failure with full diagnostic context.
Make auditability a release requirement
HubSpot's Connect and use HubSpot data sync documents configurable sync direction, field mapping, and sync-health review. Regardless of platform, operators need a durable trail that answers: what changed, which system requested it, which record version was read, which policy decided it, whether it retried, and which final state was committed.
- Dashboard conflicts by field, source, policy version, and final disposition.
- Alert on suppression propagation failure, unexplained owner changes, duplicate creates, and rising queue age.
- Keep raw source payloads long enough to investigate according to the team's data-retention policy.
- Test recovery with reversible records and a defined replay boundary.
- Require a rollback or compensation plan before enabling a new writable field.
How Unify fits
Unify Automated plays can use CRM state to qualify outbound work and return workflow context. Teams should configure each field's authority, allowed write direction, suppression precedence, and recovery behavior against their actual Salesforce or HubSpot schema before enabling broad writes.
Start using Unify to connect CRM context, signals, data, and outbound actions with explicit workflow controls.
Frequently asked questions
Is bidirectional sync the same as real-time sync?
No. Bidirectional describes direction, while real-time describes latency. A two-way integration can still process delayed batches.
Should both systems edit every field?
No. Assign an authoritative owner and permitted operation for each field or state.
Is last-write-wins a safe default?
Not for ownership, lifecycle, compliance, or human-authored data. The last arrival may be based on the oldest business state.
What is the difference between deduplication and idempotency?
Deduplication recognizes repeated events. Idempotency ensures a repeated operation produces one intended business result.
When should a retry stop?
Stop when the error is a policy rejection, stale version, invalid mapping, missing authority, or any condition that will not change through repetition.
How should recovery be tested?
Use reversible test records, simulate timeouts and competing edits, verify audit logs, contain the affected write path, and replay from a known safe boundary.
Sources
- Connect and use HubSpot data sync, HubSpot Knowledge Base, accessed September 2026.
- Making retries safe with idempotent APIs, Amazon Web Services, accessed September 2026.
- Automated plays, Unify, accessed September 2026.
