The Trap
A Typeform has been running fine for months, feeding a Zapier or Make workflow that pulls each answer into a CRM field. Someone duplicates the form to launch a new campaign, changes a question's wording, or reorders a few fields -- and the automation keeps running without errors, but the data lands in the wrong CRM fields, or shows up blank. Nothing crashed. Nothing looks broken in Typeform's UI. The mapping just silently stopped matching the answers to the right questions.
Why This Happens
Every question in a Typeform has an internal id and a ref. When a response comes in -- whether through Typeform's Watch Responses trigger or a raw webhook -- the payload identifies each answer by that question's field.id and field.ref, not by the question's visible label text. If you never set a custom ref when building the form, Typeform auto-generates one for you. That auto-generated ref is stable for that exact question in that exact form, right up until you duplicate the form or make certain structural edits -- at which point Typeform treats the duplicated or modified question as a new field and assigns it a brand-new ref.
Zapier and Make build their field mapping UI off a sample response pulled at setup time, keyed to those refs. Duplicate the form, and the new form's fields have new refs even though the questions look identical to a human reading them. The Zap or scenario built against the original form never sees that change -- it just stops finding a match for the ref it's expecting, so that field comes through empty while everything else on the form keeps working.
Where This Gets Worse
The same thing happens on a smaller scale when you edit an existing live form rather than duplicating it. Reordering questions is usually safe. But deleting a question and adding a new one that asks something similar is not the same field to Typeform, even if it occupies the same visual position -- it's a new ref, and any automation built around the old one breaks quietly rather than loudly.
The Fix
Set an explicit, human-readable custom ref on every question before connecting any automation -- something like email_address or lead_source rather than letting Typeform generate one. A custom ref you set yourself survives duplication and most structural edits, because Typeform preserves refs you explicitly defined rather than regenerating them the way it does with auto-assigned ones.
If you're already past that point and inherited a form with auto-generated refs, pull a fresh response payload through Typeform's Create/Update a Webhook endpoint or the Typeform API directly and compare the current field refs against what your Zap or Make scenario has mapped, rather than assuming a visual check of the form is enough.
Actionable Considerations
- Set custom refs before launch: this is a five-minute step per form and the single highest-leverage fix, since it prevents the whole class of problem rather than requiring ongoing vigilance.
- Treat form duplication as a rebuild, not a copy: re-check every downstream mapping any time a form is duplicated for a new campaign, even if the questions are word-for-word identical.
- Use Typeform's Update a Form endpoint deliberately: editing a form through the API with explicit ref values is more predictable than editing through the UI when you need refs to stay fixed.
- Test with a real submission after any edit: a dry-run submission through the live form, checked against what actually lands in the CRM or spreadsheet, catches a broken mapping immediately -- waiting for a real lead to notice is the expensive way to find out.
Silent field-mapping drift like this is one of the more common ways a working integration quietly degrades without ever throwing an error. For more posts on diagnosing this kind of gap, see the implementation guides on the blog.