Your Intake Form Works Fine — Except It's Silently Dropping Data

The form works. People fill it out, hit submit, land on a thank-you screen. Records appear in Salesforce. Everyone moves on.

Months later someone runs the report a funder asked for — applicants by race and ethnicity — and the column is empty. Not partially empty. Empty, across a thousand records, going back as far as the form has existed. Nothing was ever logged as an error. No one did anything wrong that they can see.

What happened is one of the quietest failure modes in any custom form: a field on the form was wired to a field that doesn’t exist in the database.

How a value goes nowhere

Custom forms — screen flows, Lightning Web Components, web-to-anything — map their inputs to fields by API name, as plain strings. A dropdown labeled “Race / Ethnicity” gets pointed at Race__c. But the field that actually exists on the record is Ethnicity__c. Nobody notices, because nothing in the build process forces the two to agree.

When the form saves, the valid fields — name, email, phone — write perfectly. The value aimed at Race__c has nowhere to land, so it’s simply dropped. The save still succeeds. The record is created. The thank-you screen still shows. The only thing missing is the one field nobody looks at until a grant report needs it.

I’ve opened a “working” intake form and found four fields wired this way — race, housing status, a business phone, a website — every one of them silently discarded on every submission for the life of the form. The form had been treated as a success. It was, for the fields anyone ever checked.

Why clicking would have caught it and building didn’t

Add a field to a page layout in the UI and Salesforce won’t let you reference one that doesn’t exist — you pick it from a list. Build the same form as a flow or a component and the field reference is just a string you typed. A typo, a renamed field, a mapping copy-pasted from a different object — any of them deploys without complaint, then fails silently at runtime for that field alone.

The demographic fields are the usual casualties precisely because they’re optional. Required fields get noticed the moment they’re missing. Race, disability, veteran status, housing type — the fields that exist only for reporting — can be dropped for years before anyone runs the report that needs them.

There’s a close cousin worth knowing — same symptom, different cause: a field that does exist but was deployed with no field-level security. The form writes to it happily while every human query, even an admin’s, swears the field is empty. Same vanishing act, one layer deeper in the stack.

The fix is a round-trip, not a review

You cannot eyeball this. A form that looks like it works and a form that saves every field are different claims, and only one of them is testable.

Submit a test record with every field filled in — including the optional demographic ones — then pull that record back up and compare what you entered against what saved. Anything blank is a broken mapping. Fix the field name, resubmit, confirm it round-trips.

Do it once per field, deliberately, especially for the fields that exist for grant reporting and nothing else. It takes ten minutes, and it’s the only thing that separates a form that works from a form you’ve watched work.

The same instinct pays off one layer down: records can carry values their own picklist doesn’t allow, which drop silently out of any report filtered on the proper values. Empty columns and missing rows are usually the same story told twice.

If you keep one habit from this: a green thank-you screen confirms the record saved. It says nothing about which fields saved. Round-trip the ones that matter before a funder does it for you.