Two-Way Sync Without Tears: Keeping SaaS Records Consistent

Two-way sync sounds simple: “keep System A and System B in agreement.” In practice, it is one of the fastest ways to create duplicate records, overwrite good data with stale data, and spend weekends unraveling why numbers changed.

The good news is that you do not need an enterprise integration platform to do this well. You need a clear definition of ownership, a small set of matching rules, and a predictable reconciliation routine that surfaces ambiguity instead of guessing.

This post walks through a pragmatic strategy you can use whether you are syncing a CRM with an email tool, an accounting system with a subscription system, or an internal database with a SaaS source of truth.

Start with ownership, not technology

Most sync failures are not API failures. They are policy failures: nobody decided which system “owns” which fields. If both systems can edit the same field and you do not define precedence, the sync will eventually pick the wrong winner.

Start by writing down, for each object you are syncing (contacts, companies, invoices, subscriptions), which system is the system of record for:

• Identity fields (email, external customer ID)
• Lifecycle fields (lead status, active vs cancelled)
• Financial fields (balance due, plan price)
• Communication fields (opt-in status, suppression)

A workable rule of thumb: let each system own the fields it is best at producing. Your billing system should own invoice status. Your CRM should own lead stage. Then your sync becomes a controlled update pipeline rather than a tug-of-war.

Pick a sync model you can explain

“Two-way sync” is a bundle of different designs. Choose the simplest model that meets your needs, and be explicit about what is not synced.

Three common models

1. One-way with enrichment: System A publishes canonical records; System B adds extra fields that never flow back. This is often enough.
2. Two-way with field ownership: Both systems can create records, but specific fields flow in only one direction. This is the most maintainable form of two-way sync.
3. Hub-and-spoke: A central “integration store” (a small database or even a dedicated table) holds canonical IDs and last-seen state; System A and B sync with the hub, not directly with each other.

A concrete example: a small agency uses a CRM for contacts and an invoicing tool for billing. They want new paying customers (from invoicing) to appear in the CRM automatically, and they want the CRM’s contact details to update the invoicing tool. That is two-way, but with ownership:

• Invoicing owns: customer status (paying), invoice totals, delinquent flags.
• CRM owns: name formatting, phone number, sales owner, lifecycle stage.
• Neither auto-wins: email changes (needs review, because it affects identity).

This policy prevents the classic failure where a salesperson “fixes” a phone number in the CRM and a nightly job overwrites it with an older number from billing.

Matching rules: how records find each other

Sync starts with matching. If you match poorly, everything else is damage control. Your goal is to create a stable relationship between “the same person” or “the same company” across systems.

Prefer matching in this order:

1. Explicit cross-system IDs stored in both places (best)
2. A dedicated mapping table in your integration store (excellent and often easier)
3. Stable natural keys like verified email, but only with guardrails
4. Fuzzy matching (name, domain similarity) only for suggestions to a human reviewer

In practice, the mapping table approach is the workhorse. You create a record once, store {systemA_id, systemB_id}, and from then on you never need to guess again. If a record is created in either system later, you do not “search by name,” you link it and store the mapping.

If you must use email as a key, treat email changes as a special case. Email often functions as identity and communication channel, so changing it can break matching and deliverability. Make the change go through a review step.

Reconciliation runs: the safest default

Many teams start by wiring “whenever something changes in A, push to B.” That can work, but it amplifies mistakes. A safer default is a reconciliation run: pull current state, compute differences, apply only allowed updates, and record what happened.

Conceptually, a reconciliation run looks like this:

for each mapped_record (A_id, B_id):
  A = fetch(A_id)
  B = fetch(B_id)

  diff = compare(A, B)
  proposed_updates = apply_field_ownership_rules(diff)

  if proposed_updates is empty: continue
  if proposed_updates contains identity_or_conflict: send_to_review_queue
  else: update_target_system(proposed_updates) and log_result

This structure forces you to be explicit about what changes are allowed. It also creates a natural place for safety checks like “do not update if last modified is newer than X” or “do not change this field unless it is currently blank.”

Operationally, you can run reconciliation:

• On a schedule (for example, every hour) for predictable load
• On-demand after major imports
• As a follow-up to real-time events (event triggers a targeted reconciliation for one record)

The key is that reconciliation is repeatable. If something goes wrong, you can re-run it, and because you are applying rule-based diffs rather than overwriting entire records, you limit blast radius.

Conflicts and edge cases: plan for the weird stuff

Edge cases are not rare in sync systems. They are inevitable. The trick is to pick predictable behaviors for each class of weirdness and to make “no change” an acceptable outcome.

Conflicts: both sides changed the same field

This is where field ownership saves you. If a field is owned by System A, then A wins for that field. If neither owns it (like email), do not pick a winner automatically. Put it in a review queue with context: old value, A value, B value, timestamps, and links to the records.

Deletes, merges, and re-creates

• Deletes: consider “soft delete” flags. Hard deleting in one system and mirroring it can destroy history in the other. Often the right move is “stop syncing and alert.”
• Merges: CRMs commonly merge contacts. Your mapping table must support “many-to-one” history (old IDs pointing to a new canonical ID), or you will resurrect merged duplicates.
• Re-creates: when a record is deleted and later re-added, it may get a new ID. Your sync should detect “same natural key, different ID” and require human confirmation before remapping.

Rate limits and partial failures

Assume APIs will rate limit you and that requests will fail mid-run. Design your reconciliation to be restartable: record progress, avoid multi-step updates that must all succeed, and keep changes small. If you hit a rate limit, pause and resume rather than skipping records silently.

Common mistakes that create data drift

• No ownership rules: “sync everything both ways” leads to last-write-wins chaos.
• Matching by name: “Acme Inc” vs “ACME” becomes two companies forever.
• Overwriting whole records: sending an entire payload back and forth causes accidental field resets.
• No audit trail: if you cannot answer “why did this field change,” trust erodes and teams turn the sync off.
• Ignoring time: timestamps differ across systems; treat them as hints, not absolute truth, unless you control both sides.

If you only fix one thing, fix auditing: log what you intended to change, what the API returned, and which rule allowed it. This turns mysterious drift into debuggable incidents.

When not to build a two-way sync

Two-way sync is attractive because it promises flexibility, but it also creates a long-lived maintenance surface. Consider alternatives when:

• You only need reporting: pull both sources into a reporting store instead of trying to keep them identical.
• One system is clearly authoritative: implement one-way sync and stop there. “Nice to have” backflow often causes the most trouble.
• The object model does not align: if System A’s “company” does not map cleanly to System B’s “account,” you will spend time on lossy transformations and edge cases.
• You cannot staff ongoing support: if nobody owns integration ops, a simple manual workflow may be safer than automation that fails quietly.

A good compromise is “one-way plus alerts”: push canonical updates in one direction and alert humans when the other system diverges. You still get visibility without forcing the sync to resolve every disagreement.

Copyable checklist for a sync you can maintain

Use this as a launch checklist before you turn on a sync job (especially if it touches customer or financial data).

• Scope
  • List the objects being synced (contacts, companies, invoices).
  • List the exact fields being synced for each object.
  • Write down what is explicitly out of scope.
• Ownership rules
  • Assign a system of record per field.
  • Define “review required” fields (identity, compliance-related preferences).
  • Define “only fill if blank” fields to prevent clobbering.
• Matching
  • Choose a stable matching key strategy (prefer mapping table).
  • Document how new records are linked.
  • Decide how to handle duplicates detected during matching.
• Reconciliation design
  • Compute diffs and apply field-level updates, not full overwrites.
  • Make runs restartable and safe to re-run.
  • Set a maximum batch size per run to control blast radius.
• Observability
  • Log each update with: mapping IDs, changed fields, rule used, API response.
  • Create a simple dashboard view: processed, updated, skipped, conflicts, errors.
  • Route conflicts to a review queue with enough context to decide quickly.
• Rollout
  • Start in “dry run” mode: compute diffs and log, but do not update.
  • Enable updates for a small segment first (for example, 50 records).
  • Schedule a review after the first full run and refine rules.

Conclusion

Two-way sync becomes manageable when you stop treating it as a magical mirror and start treating it as a policy-driven reconciliation process. Define who owns what, match records with stable identifiers, apply changes through diffs, and route ambiguity to humans instead of guessing.

If you do those four things, your integration will feel boring, and boring is exactly what you want for data consistency.

FAQ

Do I need real-time updates, or is a scheduled job enough?

For most back-office and CRM scenarios, a scheduled reconciliation (every 15 to 60 minutes) is enough and is easier to debug. If you need fast updates for a specific workflow, trigger a targeted reconciliation for just that record.

How do I handle duplicates that already exist in both systems?

Start with a one-time cleanup: pick canonical records, merge where appropriate, then establish a mapping table so you do not have to re-detect duplicates repeatedly. Avoid fully automated merges unless the match is unambiguous.

What is the minimum audit log I should keep?

Record the two system IDs, the fields changed, old and new values when feasible, the rule that authorized the change, timestamps, and the API result. This is usually enough to answer “what changed and why” without storing full payloads.

How can I reduce the risk of overwriting good data?

Use field ownership, prefer “fill if blank” for non-critical fields, and run in dry-run mode before enabling writes. Also cap batch sizes so a rule mistake affects a small set of records, not your whole database.