Quick Bridge — bi-directional QuickBooks ↔ Salesforce sync

Context

A client needed QuickBooks and Salesforce kept in sync — both directions. Finance lives in one, the sales pipeline in the other, and the same customer and invoice records exist in both.

Why bi-directional is a different problem

One-way sync is data transfer: read source, write destination, done. Bi-directional sync is conflict resolution. Both systems accept edits, so the same record can change on both sides between sync runs, and the engine has to decide what actually happened.

The cases that define the design:

• The same field edited on both sides since the last run.
• A record created in both systems representing the same real entity.
• A deletion on one side against an edit on the other — the case where guessing wrong destroys data.

Approach

Sync state is tracked per record and per field, not per run, so the engine can tell what changed rather than only that something differs. Field-level change tracking means simultaneous edits to different fields of the same record merge cleanly instead of one side clobbering the other — which turns out to be the majority of real-world conflicts.

Genuinely ambiguous conflicts — same field, both sides, no clear precedence — surface for human resolution rather than being resolved by a silent last-write-wins rule. Financial records are the wrong place to guess.

Delivered as a desktop application: C# for the sync engine, Electron for the interface.

Stack

C# · Electron.js · QuickBooks API · Salesforce API