What this service solves
Keep one CRM object consistent across two systems that both receive edits. Agree on how records match, which system is authoritative for each field, and when a change should wait for review. The sync distinguishes incoming edits from its own updates and sends unresolved conflicts to one queue.
What you get
Bidirectional sync
Both directions use the reviewed field map and a conflict policy. Repeated events and echoed updates follow the agreed suppression rules.
Conflict queue and reconciliation
The owner can review divergent records and compare the two systems after a replay, correction, or recovery step.
What’s included
Define field authority and identity
Choose the cross-system identifier and field authority. Confirm how a blank, an inactive record, or an ambiguous match is represented on each side.
Implement bidirectional changes and conflict detection
Build both change paths using the providers' supported update behavior. Track event origin or a comparable source reference to prevent updates from cycling.
Reconcile divergent records
Hold unresolved conflicts for review and compare the records using their shared identifiers. Record the decision or disposition before reconciling the difference.
How implementation works
Approve field ownership
Review sample conflicts and approve field ownership and matching rules before building writes.
Build both directions
Implement both directions in the sandbox and check the update markers and conflict queue with representative records.
Test replay, conflicts, and rollback
Exercise a repeated event, simultaneous changes, and the agreed rollback path. Review reconciliation before acceptance.
Technical considerations
- Identity and field authority
- Choose a stable shared key for one object type. Define which system owns each of the mapped fields, how either tool represents a blank, and when a missing or ambiguous key should stop a write.
- Provider change behavior
- Verify authorization, usable change metadata, and update behavior on both sides. Agree on a supported way to recognize an echoed update and on what information the reviewer needs in the conflict queue.
Systems, inputs & prerequisites
Sandbox access, a stable cross-system key, field ownership, and example conflicts.
- Authorized sandbox access, API change and update semantics, and a stable cross-system key.
- Examples of conflicting edits, blank values, repeated events, and the owner who resolves each case.
Starting scope & pricing
Base scope
Two supported systems, one object type, up to twelve fields, and one conflict queue.
Illustrative workflow
Match records
Use the shared identifier to find the corresponding record in each tool.
Apply authority
Update an authoritative field when the rule is clear, or open one conflict for review.
Reconcile
Verify the final values and suppress the resulting echo event.
Validation & handover
- Verify matching and approved field ownership on representative records in both directions, including an intentional blank or inactive state.
- Replay an observed sample event and exercise an edit from the other system. Confirm that an echoed update is suppressed and both genuine edit directions still work.
- Simulate competing edits in the approved test environment and confirm the intended conflict disposition. Reconcile the two values and walk through the reviewed rollback procedure.
Limitations & possible extras
Limitations
Additional objects, historical backfill, higher event volume, and custom middleware need separate scoping. Reliable bidirectional sync depends on supported identity and update behavior in both systems.
True bidirectional behavior needs stable identifiers and update semantics on both sides.
Possible extras
Provider tiers, backfill, custom middleware, and higher event volume.
Questions about this service
Which edit wins when both systems change a field?
The approved field authority and conflict rules determine the result. A simultaneous edit without a clear winner goes to the single conflict queue for review.
Can we begin with a historical backfill?
Historical data has separate identity, volume, and reconciliation risks. Review that work independently of the starting sync for current changes.
What if the shared record identifier is missing or reused?
The record needs the agreed exception path before either system is updated. Review representative missing or ambiguous matches when establishing the shared key.
Can we get bidirectional sync when a provider only exposes read access?
Both sides need supported updates for the fields assigned to them. Scoping checks available permissions and change information before committing to a direction or proposing a narrower transfer.