The worst automation bugs are not the ones that break. Those get noticed. The worst ones succeed — every execution green, every log clean — while quietly doing less than you think.
I ran into one of these on a Make.com scenario that syncs patient intake submissions from IntakeQ into a Monday.com CRM. Patient fills in an intake form, a webhook fires, the scenario pulls the full record from the IntakeQ API, works out which form type it is, and creates or updates that patient on the right board. No manual data entry, no copy-paste between systems.
It worked. Mostly. One form type never arrived on the board, and nothing anywhere said so.
Why routing bugs hide
A scenario that routes by form type has to make a decision: this submission goes down path A, that one down path B. When the decision is wrong, the bundle does not error. It just takes a path where nothing matches, reaches the end, and stops. Make records a successful execution, because nothing failed — the work simply had nowhere to go.
So the failure is invisible from the place you would naturally look. The execution history is green. The error log is empty. The only symptom is on the CRM board, where records that should exist do not, and you only notice if you happen to be counting.
That is what makes routing worth checking first when a sync is partially working. Partial success points at a decision, not at a broken connection — a broken connection fails loudly and fails for everything.
Two more problems in the same scenario
Fixing the routing surfaced two others worth describing, because both are the same category of quiet wrongness.
The first was duplicates. A returning patient submitting a second form created a second record rather than updating the first, so one person gradually became several. The fix was matching on two keys instead of one: check email first, fall back to phone, and update the existing record when either matches. One key is rarely enough, because people change their email, mistype it, or fill in the form from a different address than last time.
The second was dates. The IntakeQ API returns date fields as Unix timestamps, which the CRM does not read as dates — they import as invalid values. That needed explicit format conversion, plus validation so only clean dates reach the CRM at all. A field holding a wrong value is worse than an empty one, because an empty field is at least obviously empty.
Naming every module
The last thing I did was rename every module in the scenario to say what it actually does.
This sounds like housekeeping. It is really debugging infrastructure. A scenario made of modules called "HTTP", "Router", and "Monday.com" tells you nothing when you open it six months later — you have to click into each one to rebuild the logic in your head. That reconstruction cost is what makes people avoid touching a working automation, which is how small problems survive for months.
If a sync is only partly working
Worth checking, roughly in this order:
- Compare counts, not statuses. Green executions tell you nothing when the failure mode is a bundle going nowhere. Count records that should have arrived against records that did.
- Suspect the routing first. If some records sync and others do not, the difference is a decision the scenario is making, not a connection that is down.
- Check what the filter actually compares. Form names and IDs drift; a filter written against last year's label will not match this year's form.
- Inspect the values that arrive, not just whether fields are populated. Timestamps, empty strings, and nulls can all look like data until you look closely.
- Match on more than one key when deduplicating. Email alone will let duplicates through.
None of this is specific to Make.com. The same silent-skip failure exists in n8n, Zapier, and anything else that branches on a condition — the platform reports the execution, not the intent.