This is a teardown of a problem, not a client story. There is no anonymised customer here and no invented metrics — just the pattern as it actually appears, and what dealing with it involves.
Four thousand unresolved sync errors is the figure I see most often when I open an inherited Account Engagement org. Nobody put it there deliberately. Nobody is monitoring it. And almost nobody can tell you what it is costing them, because the damage is invisible until someone runs a report and the numbers do not reconcile.
The short version
- Sync errors are not one problem. They are typically four or five different failures sharing one queue.
- They accumulate silently because the connector keeps working for everything else.
- The cost is not the errors — it is that every downstream report, list and hand-off is quietly wrong.
- Clearing them is mostly diagnosis. The fixing is fast once you know which of the five you have.
What is actually in that queue
Open the sync error log in a neglected org and the entries almost always sort into the same handful of causes.
1. Required fields on the Salesforce side
Someone added a validation rule or made a field required on Lead or Contact. Account Engagement tries to write a record that does not satisfy it, and the write fails. This is the single most common cause, and it is usually introduced by a Salesforce admin who had no idea a marketing tool was writing to that object.
2. Field type and length mismatches
A picklist on one side, free text on the other. Or a Salesforce field with a 40-character limit receiving a 60-character value. These fail one record at a time and never announce themselves.
3. Duplicate matching collisions
Two prospects with the same email, or a Lead and a Contact that both match. The connector cannot decide which record wins, so it does nothing. These are the errors that most often correlate with sales complaining that “the data is wrong”.
4. Deleted or merged records
A Salesforce record gets merged; Account Engagement still holds a reference to the losing record. Every subsequent sync attempt on that prospect fails forever.
5. Permission problems on the connector user
The connector user loses field-level access after a profile change. This one is nasty because it can fail thousands of records at once, and it is invisible unless you check the connector user’s permissions specifically.
Why it grows without anyone noticing
The connector does not stop. That is the whole problem.
If a sync failure halted the integration, someone would notice within the hour. Instead, the failure is per-record: 99% of your prospects sync fine, and the 1% that do not simply drift out of alignment. Marketing sees one version of a prospect, sales sees another, and both believe their own screen.
The second reason is that the error log is a page nobody has a reason to visit. It is not on a dashboard, it does not send a digest, and it does not appear in any report a marketing manager runs. In most orgs I audit, the answer to “when did someone last look at this?” is a shrug.
What it actually costs you
Not the errors themselves — the decisions made on top of them.
- Lead routing. A prospect whose company or owner field never synced gets routed to the wrong rep, or to nobody.
- Scoring. Activity recorded in Account Engagement that never reaches the CRM means sales sees a cold record for someone who has been on your pricing page four times.
- Reporting. Connected Campaign attribution silently under-counts, so the channel that actually works looks mediocre in the board deck.
- Suppression. This is the one that can hurt legally — an unsubscribe or consent withdrawal that fails to sync means you keep mailing someone who asked you not to.
That last point is why I treat a sync backlog as urgent rather than as housekeeping.
How to check yours in about ten minutes
You do not need me for the first pass:
- Open the connector’s sync error log and note the total count and the oldest entry date. The date matters more than the count — it tells you how long this has been unattended.
- Group the errors by message. You will almost certainly find that two or three messages account for most of the volume. That concentration is good news: a handful of root causes, not four thousand individual problems.
- Check the connector user’s profile and field-level security against the fields you actually sync.
- Run the Import Pre-Flight Check against your next import file — a lot of sync errors are created upstream, at import time, and never fixed at source.
If the oldest entry is more than a few months old and the top three messages cover most of the volume, you have the standard pattern and it is very fixable.
What fixing it involves
The work is roughly 70% diagnosis and 30% repair, which surprises people who expect it to be a long clean-up slog.
Diagnosis means grouping the backlog by root cause, checking each against the Salesforce side, and deciding which records are worth recovering versus which should be written off deliberately. Not every failed record deserves rescue — some of them are genuinely dead, and pretending otherwise turns a two-week job into a two-month one.
Repair means fixing the cause (the validation rule, the field mapping, the permission) and then replaying the affected records. Then, crucially, putting monitoring in place so the number does not silently climb back — because it will, the next time a Salesforce admin adds a required field.
What this costs
The diagnosis is part of the Express Health Check (A1, €900) — it counts and categorises the backlog and tells you which of the five causes you have. If the repair is worth doing, the Sync & Data Quality Rescue (F5) covers root-cause fixes, record replay and the monitoring that stops it recurring. Fixed scope, fixed price, capped in writing.
And if your backlog turns out to be small and boring, I will tell you that and you will have spent €900 to stop worrying about it.
The honest bit
A four-figure sync backlog is not evidence that your team is careless. It is the default outcome of a connector that never complains, an error log nobody owns, and two systems administered by different people. Almost every org I open has one.
What separates the orgs that recover from the ones that stay broken is whether anybody is watching the number. That is the actual deliverable — not a clean queue, which decays, but somebody’s name against the job of noticing.
Seeing this in your own org?
The first call is free: thirty minutes, no slides, and an honest read on what a fix would take. If it is not worth doing, you will hear that too.