Every lead arrived saying "Name", "Email", "Phone"

A working integration producing useless data

Enquiries from a major listing portal reached the CRM by email: the portal sends a notification, a parser reads it, and a connector creates the contact. Every part of that chain reported success. Records appeared. Nothing errored.

The records were worthless. Where a buyer's name should have been, the contact said "Name". Where the email should have been, it said "Email". Same for phone, project reference, project name and address — six fields, every one containing its own label.

This is a particularly awkward class of failure because there is nothing to alert on. No queue backing up, no rejected payload, no error rate to watch. The integration is healthy by every measure except the one that matters.

The templates were pointed at the wrong half of the line

A parser of this kind learns from a sample email: you highlight the part of the message that varies and give it a token name. Get that backwards and it learns the wrong thing.

Both templates had been built with the tokens sitting on the labels rather than the values. The parser had been told, in effect, that the part which varies between emails is the word "Name:" — and that the buyer's actual name was fixed boilerplate. It then did exactly what it was configured to do, on every lead, for as long as it had been running.

Both templates carried the same mistake, which is worth noting: the second one had presumably been created by copying the first, so the fault propagated rather than being caught by comparison.

Rebuilding it, including the part nobody asked about

The templates were rebuilt so the tokens capture the values: name split into first and last, email, phone, and the three project reference fields. The connector's field mapping was then completed by hand against the CRM properties, which already existed and needed no changes — the CRM was never the problem, and it would have been easy to spend a day in there looking for one.

Two fields present in the notification were left untokenised deliberately, because they were empty in the only available sample. Guessing at the structure of a field you have never seen populated is how you produce a second version of this same bug. The client was asked to forward a lead that has them filled in, so they can be added against real data rather than an assumption.

The stale template was also corrected rather than left in place. The parser prefers whichever template best matches an incoming message, and a broken one sitting alongside a fixed one is a trap for whoever looks at this next.

Why this ran for months

Nobody was ignoring it. The failure had no surface. Sales saw contacts arriving from the portal and assumed the feed worked; whoever set the parser up saw it save successfully and assumed the same. The only place the two views meet is on the contact record itself, and by the time anyone reads one of those they are usually looking for a phone number, not auditing an integration.

The general lesson is that an integration is not verified by its own status. It is verified end to end, on a real payload, by reading the record at the far end and checking that the values in it are values.