Your Typeform Survey Is Creating Duplicate Contacts in Salesforce
The Typeform–Salesforce connector defaults to creating a new record for every response, matched on name. Why existing donors get duplicated, and the fix.
A nonprofit I work with wanted their donor survey to flow into Salesforce. The goal was simple and sensible: when a major donor fills out the form, find their existing record, freshen up their contact details, and save what they told you. The connector to do it was already installed.
It was also quietly doing the opposite. Every submission created a brand-new contact — a second, half-empty copy of a donor who had been in the database for years. The sync “worked” in the only sense anyone usually checks: data showed up. It just showed up in the wrong place.
The mechanism
Typeform’s Salesforce integration — the managed package you install from the AppExchange — runs off a field mapping. Each form question points at a field on a target object, usually Contact. Two settings on that mapping decide everything about duplicates, and both are easy to get wrong:
- Record creation behavior — whether a submission creates a new record, updates an existing one, or creates-or-updates (find a match, update it if found, create it if not). Out of the box it leans toward Create.
- The matching key — the field(s) the connector uses to answer “is this person already here?” In the org I looked at, the keys were First Name and Last Name.
Put those two together and you have a duplicate machine: behavior set to create, matching on a name — the least reliable identifier a person has.
Why matching on name fails both ways
Names are neither unique nor stable, so name-matching breaks in two directions at once:
- It misses real matches, so it makes duplicates. Bob vs. Robert, maiden vs. married name, a middle initial this time but not last time, a typo, “Jim & Pat” entered as one household contact. The connector decides “no match found” and dutifully creates a new record.
- When it does match, it can match the wrong person. Two different Sarah Johnsons collapse into one, and now a survey response — maybe a planned-gift intention — is sitting on a stranger’s record.
The duplicates are the visible symptom; the silent mis-merges are the dangerous one. And nothing errors. The form submits, a record saves, everyone moves on.
How to check your org
- Open the form’s mapping — in the Typeform app inside Salesforce, or via the Form Mapping records the package creates.
- Read the record-creation behavior and the matching key. Create plus name means you have this problem waiting to happen.
- Find what the integration has already made. The package stamps every record it touches with a lookup back to its mapping. Build a list view or report of Contacts where that field is set, sorted by Created Date — recent entries that shadow existing donors are your evidence.
- Spot-check one. Search a known respondent’s name; if there are two contacts and the newer one is sparse, that’s the pattern.
Fixing it
Switch the behavior to create-or-update. A survey almost always targets people you already have. “Create a record every time” is rarely what you actually want from a form that enriches known contacts.
Match on email, not name. Email is the closest thing a person has to a unique key. Mind the two caveats: shared household emails (a couple who use one address) and donors with no email on file — decide how each should behave rather than discovering it in production.
Decide the no-match case on purpose. When the email isn’t found, should the connector create a new contact or hold the response for review? For a major-donor survey, you may want new records created only deliberately.
Line it up with your org’s duplicate rules. The connector’s matching is separate from Salesforce’s duplicate and matching rules (and NPSP’s contact matching). If they disagree — one creating while the other blocks — you get silent failures instead of clean updates. Make them agree.
Clean up the copies already created. Merge each duplicate into the real record, carrying any survey answers across, before you flip the switch. Then watch one real submission land on the right contact before you trust it.
The deeper lesson
A form or survey connector’s real job is usually enrichment — attaching new information to people you already know. Yet these tools ship defaulted to creation, because the vendor has no way to know your data already exists. The single most important question to settle before you turn one on is: what makes a person the same person in this org? Choose that key deliberately, set the behavior to match it, and follow one real submission from form to record. “The data showed up” is not the test. “It landed on the right record” is.
I’m Chris Moore — an independent consultant in Henderson, NV. I work with small nonprofits on Salesforce cleanup and the integrations that feed it — forms, surveys, and donation platforms — including pro-bono engagements through Catchafire and Taproot. If your survey or web form is breeding duplicate contacts, get in touch.