When customer data lives in more than one cloud platform, it will eventually disagree with itself. A rep updates a phone number in one system and finds the old one back the next morning. A contact appears twice with slightly different spellings. A deal closes in one CRM while the other still shows it open. These are rarely random. They are symptoms of identifiable design and operational problems, and a methodical approach finds the cause faster than guesswork.

Start With a Clear Description of the Symptom

Vague complaints such as “the sync is broken” waste time. Capture specifics.

• Which record, field and systems are involved?
• What was the expected value, and what appeared instead?
• When did it start, and does it affect one record or many?
• Is the problem consistent or intermittent?
• Did anything change recently, such as a field edit, a permission change, a vendor release or a new integration?

Pick one clear example record and trace it end to end. Fixing one traced case teaches you more than reading logs in the abstract.

The Usual Suspects

Two systems both believe they own a field. If both can edit and both sync, last writer wins, often unpredictably. This is the most common cause of values that revert.

Mismatched identifiers. If records are matched on email address in one system and on a company-specific ID in another, small differences create duplicates or mis-merges.

Different data formats and validation rules. A field accepted in one system may be rejected in the other, such as a longer text value, a country name instead of a code or a picklist value that does not exist on the other side.

Timing and ordering issues. Near-simultaneous edits, delayed queues or batch schedules produce stale overwrites.

API limits and throttling. When a platform restricts request volumes, syncs can lag or partially fail. Check each vendor’s current documentation for the limits that apply to your plan.

Expired credentials or changed permissions. Integration accounts that lose access fail quietly if nobody monitors them.

Loops. An update in A triggers an update in B, which triggers an update back in A. Loops waste capacity and can corrupt timestamps.

Deleted or merged records. A merge in one system may not propagate cleanly, leaving orphaned references in the other.

A Troubleshooting Table

Symptom	Likely Cause	Where to Look
Field value keeps reverting	Two-way sync without clear ownership	Field-level sync rules
Duplicate contacts appear	Weak matching keys	Match rules and incoming data samples
Records missing in target	Validation rejection or filter	Integration error log
Sync delayed for hours	Throttling or queue backlog	Platform usage limits and queue status
Sudden failures for all records	Credentials or permission change	Integration user status
Endless update activity	Trigger loop	Automation and workflow rules

A Repeatable Process

1. Reproduce or observe. Make a controlled change to a test record and watch what happens in both systems.
2. Check the integration log. Look for errors, retries and rejected payloads. Confirm the log retention covers the time of the incident.
3. Compare the field definitions. Types, lengths, required status and allowed values on both sides.
4. Review the change history. Audit trails show who or what changed a value and when, which separates human edits from integration activity.
5. Inspect the matching logic. How does the integration decide that two records are the same entity?
6. Check recent changes. Releases, new automation, altered permissions and schema edits are frequent triggers.
7. Fix the cause, then the data. Repairing records without correcting the design guarantees recurrence.

Fixing the Design

The durable fixes are architectural.

Assign a single authority per field. Decide which system is the source of truth for each attribute, and make the other read-only for that field, or at least one-way synced. A system-of-record map documented in your governance material helps here.

Use stable keys. Store the other system’s record identifier in each record, and match on it rather than on names or emails alone.

Normalise data at the boundary. Standardise formats, such as country codes and picklist values, in the integration layer so both sides receive acceptable input.

Handle failures visibly. Route rejected records to a queue someone reviews, and alert on failure rates rather than relying on silence as evidence of health.

Prevent loops. Use flags or timestamps that identify integration-originated changes so they do not trigger the same sync again.

Test in a sandbox. Check the vendor’s current documentation on test environments, and rehearse schema or automation changes before production.

A Brief Hypothetical

Suppose a customer’s billing address keeps reverting in the sales CRM. The traced example shows that the sales CRM and a service platform both write to the address field every few minutes, each using its own value. The team decides the finance-owned billing system is the authority, makes the address read-only in both CRMs and syncs it one way. They then use stored external IDs to find and fix mismatched records. The reverting stops, and support tickets about wrong addresses decline. All details here are illustrative.

Clean Up Duplicates Safely

Before any bulk merge, back up the affected data and test your merge rules on a small sample. Decide which record survives and which field values win. Review related records such as opportunities, cases and activities to make sure they follow the surviving record. Merging is difficult to undo, so move carefully and log what you did.

If personal data is involved, consider how consent and deletion obligations apply to merged or removed records. Requirements vary by jurisdiction, so consult qualified legal or compliance professionals.

Prevention Through Monitoring

Create simple health checks: daily counts of records synced versus expected, error rates by integration, queue age and number of new duplicates. A small dashboard that someone reviews weekly catches problems long before users complain. Assign an owner to every integration, with a documented runbook for common failures.

Frequently Asked Questions

Is two-way sync a bad idea? Not inherently, but it demands clear field-level rules and conflict handling. One-way sync from a defined authority is simpler and safer for many fields.

Should we use middleware instead of direct connectors? It can add monitoring, transformation and error handling in one place, at the cost of another tool. Evaluate against your complexity and skills.

How do we find existing duplicates? Use the platforms’ duplicate management features where available, or export and match on normalised keys. Check current vendor documentation for what is supported.

Who should handle sync incidents? The integration owner leads, with platform administrators on each side. Escalate to vendors with a clear traced example.

How can we reduce recurrence? Document the authority for every field, monitor failures actively and require a review whenever a schema or automation changes.

Next Step

Pick one record that has recently shown a conflict and trace it through both systems, step by step, using the process above. Whatever rule you discover is probably failing for many other records too.