Sooner or later someone reports that a customer’s details differ between the CRM and the billing system, or that new leads stopped appearing. Sync problems are rarely mysterious once you work through them methodically, but under pressure people tend to jump to fixes: re-run the job, re-enter the data, restart the connector. That may clear the symptom while leaving the cause in place.

This article gives a diagnostic routine you can follow regardless of which tools sit on either side of the connection.

Step One: Describe the Failure Precisely

Vague reports waste time. Capture:

• Which records are affected, and which are fine
• Which direction is failing: into the CRM, out of it, or both
• When it last worked, and what changed around then
• Whether the failure is total, intermittent or limited to specific records

Patterns carry information. If every record fails, suspect authentication or connectivity. If only some fail, suspect data content, validation rules or mapping. If it started on a specific date, look for changes made that day.

Step Two: Check Connectivity and Authentication

The most common cause of a sudden total failure is a credential problem. Passwords expire, tokens are revoked, authorizations lapse, and integration accounts get disabled when the person who created them leaves. Confirm that the integration user is active, has the required permissions and has not been locked or restricted by a security policy change. Prefer dedicated integration accounts, not personal ones, so staffing changes do not break production flows.

Also check whether network restrictions, such as allowed IP ranges or firewall changes, are blocking the connection.

Step Three: Read the Logs Before Changing Anything

Connectors, middleware and the CRM itself usually record why a record failed. Read error messages carefully and group them: many errors usually share a few root causes. Typical messages point to required fields missing, values not allowed by a picklist, text too long for a field, invalid references to other records, or violations of validation rules.

Resist retrying blindly. If a failed job is repeated with the same data, it will fail the same way and may create noise or partial duplicates.

Step Four: Examine Mappings and Schema Changes

Integrations assume a certain shape of data. When an administrator renames a field, changes a field type, adds a required field, or removes a picklist value, a previously healthy sync can start failing. Ask whether any configuration changes occurred on either side recently. A change log or release record for the CRM makes this far quicker.

Check vendor-side changes as well. Platforms evolve, and the vendor’s current documentation and release notes may describe changes that affect interfaces or behavior.

Step Five: Look for Volume, Limits and Timing

Intermittent failures often involve limits. Many platforms restrict how many requests can be made in a period, and bulk loads, large imports or overlapping jobs can trigger throttling. Check the documented limits and your job schedules. Spreading jobs, batching requests and adding sensible retry behavior with delays typically helps. Timing overlaps can also cause conflicting updates when two processes touch the same records at once.

Step Six: Investigate Duplicates and Conflicts

If records are duplicated or values keep flipping, the cause is usually a matching or conflict problem. Check what identifier the integration uses to match records. Matching on names or emails alone invites duplicates; stable unique IDs are safer. Also check whether two systems both believe they own a field and overwrite each other. Establish a single source of truth per field and align sync direction to it.

Diagnostic Quick Reference

Observation	Likely Cause	Where to Look
Everything stopped at once	Expired credentials or disabled integration user	Authentication settings, user status
Some records fail	Validation rule or data content problem	Error logs, field rules
Started after an admin change	Renamed field or changed type	Change history, mappings
Intermittent failures	Rate limits or overlapping jobs	Job schedules, documented limits
Duplicates appearing	Weak matching key	Match logic, identifiers
Values keep reverting	Two systems overwrite one field	Sync direction, source of truth

A Realistic Example

Imagine a hypothetical team whose new customer records stopped reaching the billing system. The first report says “the integration is down.” Following the routine, the administrator notes that new records fail while older updates succeed, so it is not total. The logs show repeated rejections for a missing value in a field.

Checking the change history reveals that a week earlier, someone made a new field required in the billing system without telling the CRM team. The CRM was not sending that field. The fix is to add the field to the mapping with a sensible default, reprocess the failed records, and agree that schema changes on either side require notice to the integration owner. The problem was a communication gap, not a technical fault.

Fix the Cause, Then Recover the Data

Resolve the root issue first, then reprocess failed records in a controlled way, ideally a small batch to confirm success before the rest. Afterward, reconcile counts between systems to confirm nothing is missing or duplicated. Where records were manually patched in the meantime, verify that the sync does not overwrite those corrections unexpectedly.

Build Early Warning Into the Design

Prevent the next surprise by monitoring. Alert on failed jobs, rising error counts and stalled sync times, and send alerts to a team mailbox or channel rather than one person. Keep a short runbook per integration: what it does, who owns it, where logs live, and the first three checks. Sync problems found by monitoring are an inconvenience; those found by customers are a reputation issue.

Frequently Asked Questions

Should we just re-run the failed job? Only after you understand why it failed. Re-running without a fix repeats the failure and can add duplicates or confusion.

Why did a working integration suddenly fail? Common triggers are expired credentials, configuration changes on either side, new validation rules, platform updates or increased volume.

How can we prevent schema changes from breaking syncs? Require change notices to integration owners, test in a sandbox first, and keep mappings documented.

Who should be alerted when a sync fails? A shared team channel or mailbox with a clear on-call or owner, not one individual’s inbox.

How do we know whether systems are in sync? Regular reconciliation of record counts and key values between systems, plus spot checks on recent records.

Next Step

Choose your most business-critical integration and write its one-page runbook: purpose, owner, log location, key credentials owner and the first three diagnostic checks. Add an alert for failed runs if one does not exist.