Key takeaways
- A phone number was required on a form, sent four separate ways by the site, and stored by nobody. One field in the automation behind it read from the contact it was in the middle of creating, rather than from the message that had just arrived.
- So it read an empty value and wrote that empty value into the record. No error, no failed step, and the run reported success every single time.
- The emails kept going out, which is what made the whole thing look healthy while every one of those people was dropped out of the entire text track.
- The submitted numbers are not recoverable from any log anywhere. The fix is only ever forward.
- The check that catches this is sending one real submission and reading what landed. Reading the configuration is what let it ship in the first place.
We were checking why an event was getting fewer confirmations than registrations, and the first thing we looked at was the contact records. Four of them had no phone number.
Which should not have been possible. Phone was a required field on the form. You could not submit without it.
The field was pointing at itself
Here is how that side of the system works. The website posts the form to a webhook. A workflow on the other end catches it and builds a contact out of the values in the message, one field at a time, and each field is filled by a small placeholder that says where to read from.
First name, last name and email were all reading from the incoming message. Correct. Phone was reading from the contact.
Not from a contact that already existed. From the contact the automation was creating in that exact moment, a record that had been alive for a few milliseconds and had nothing in it yet. The field asked itself what the phone number was, got nothing back, and wrote nothing into the slot it was supposed to be filling.
Nothing about that produces an error. It is a valid placeholder. It resolves to an empty string, which is a legitimate value, and writing an empty string over an empty slot is a successful write. The run finished green.
The site had been sending the number four different ways at the same time, in four differently named fields, which is the sort of belt and braces you do when you want to be certain a value arrives. All four were sitting in the message. The automation read none of them.
The part that actually cost money
A blank field on a contact is annoying. It is not two weeks of silence on its own.
What made it expensive is that everything downstream was written correctly. The note on the contact quoted the phone number. The internal alert text to the team quoted the phone number. The reminder sequence, eight messages long, was built entirely on the phone number.
All of them were reading the right place. The right place was empty. So the note came out with a gap in it, the alert never went, and every one of those registrants got zero of the eight reminders.
Meanwhile the email track was untouched, because email runs off the address, and the address was fine. Confirmations went out. Reminders by email went out. Anyone glancing at the automation saw messages flowing and concluded it was working.
That is the shape worth remembering. A partial failure that leaves the loudest channel intact does not look like a failure at all. It looks like a quiet week.
The numbers are simply gone
We went looking for the submitted values so we could put them back, and this is the genuinely uncomfortable part.
The trigger log records that the webhook fired and that it qualified. It does not keep the body. The trigger record itself carries no sample of what arrived. We tried several read endpoints that looked like they might hold a history and every one of them returned nothing.
The site had no database of its own, because it did not need one. The customer relationship manager was the database. So for those two weeks the numbers existed only in flight, for the second it took the message to travel, and then they were gone.
Four people. Real ones, who typed their number into a required field and had every reason to believe somebody had it.
The only test that would have caught it
The fix took about ten minutes. Point the field at the incoming message like the other three, push the change, done.
Proving it was the part that mattered, and we did not prove it by reading the corrected configuration. Reading the configuration is exactly what would have passed two weeks earlier, because the configuration always looked plausible. We sent a real submission through the live form with a real number in it, opened the contact that came out the other side, and read the number off the record.
That is the whole method. Structure is a claim. A record is evidence.
What this means for your business
You almost certainly have a form feeding a system somewhere, and you almost certainly have never watched one all the way through.
Do that this week. Fill in your own contact form with your own details, then go and open the record it created and check every field arrived. Not most of them. Every one. It takes four minutes and it is the only check that reads what shipped rather than what was intended.
Then ask a second question about whatever went missing: what else depends on it. A blank field is rarely the damage. The damage is the four things reading that field which now quietly do nothing, while the one channel that does not need it keeps running and keeps you confident.
Any Go High Level San Jose operator who has been at this a while will tell you the same thing. The bugs that cost you are not the ones that throw errors. They are the ones that report success.
Want this built for you
We build CRM automation that gets checked with real submissions, not diagrams, plus the websites and funnels feeding it. Start at optechsol.llc.