Duplicate submission filter: when the same person fills your form twice

Tuesday, 9:40 a.m. Marketing ran a webinar announcement overnight and the registration form collected 214 submissions. A sales rep opens the list, works through the first thirty calls, and on the third one hears the same voice twice: "We already spoke this morning." The person had filled the form in twice — once with a personal address, once with a work address, because no confirmation email arrived the first time. Two rows in the list, two owners, two separate call histories. Nobody made a mistake. The form worked exactly as built; it simply treated one person as two.

This piece walks through the problem in order: why a second submission arrives at all, what actually makes a record a duplicate, how to pick a matching key, what to do when a repeat comes in — merge, update or ignore — which fields may be overwritten and which must be protected, why duplicate filtering is not spam protection, what merging does to ownership and reporting, what changes on the personal-data side, and the order in which to configure the form before it goes live.

Why does the same person fill in the same form twice?

Most duplicates are not malicious; they come from uncertainty. Someone clicks submit, the page hesitates for a second, the thank-you screen either never appears or goes unnoticed, and they submit again. Or they saw the campaign through two channels — once in search, once in a newsletter — and filled in both without thinking twice about it.

The second big source is identity drift. Full name in one submission, first name only in the next. Mobile number here, switchboard number there. Personal inbox first, company inbox second. One human being, three different keys. This gets sharper in booking flows: when a visitor both submits a form and uses a scheduling link that writes straight into the CRM, the same person enters through two different doors.

The third source is time. The same contact downloaded a price sheet six months ago and requested a demo today. Both are real and both matter, but they are not two people — they are two touches from one person. That is the first question a duplicate rule has to answer: are you deduplicating the person, or the request?

• Technical repeat: the page lagged, the visitor pressed submit twice. Identical content, seconds apart.
• Channel repeat: the same campaign seen in two placements, submitted twice.
• Identity repeat: the same person arriving with a different email or phone number.
• Time repeat: two separate moments of interest, months apart, one person.

When exactly does a submission count as a duplicate?

Duplication is a decision rule, not a technical equality check. "The same row was written twice" and "the same human wrote twice" are different problems and need different answers. The first is usually a burst of identical submissions seconds apart, and a short time window handles it. The second is a data-model question: which field identifies a person?

In practice you set three thresholds together. First the key match: which field or fields, when equal, mean the same person. Second the time window: how long that match stays valid. Third the action: what happens when it matches. A filter built without writing all three down is either so aggressive it swallows genuine enquiries, or so loose it stops nothing.

Rocketly's Form Builder makes that decision concrete through its duplicate submission filter: repeat submissions arriving with the same email or phone number are merged into a single contact, and no second CRM record is opened. The submission is kept; the person does not multiply. Cleaning up the crowd that already built up inside the CRM is a separate job — we covered how to find and merge duplicate leads step by step elsewhere. The form-side filter exists so you do not have to repeat that cleanup.

Should the matching key be email or phone number?

Email is written more consistently but multiplies easily — one person can hold three addresses. A phone number is a more unique identity, but its formatting is messy: leading zeros, country codes, spaces and dashes. If you want to key on phone, you first have to write a normalisation rule — always store the country code, strip spaces and dashes, drop the leading zero. Without that rule, every formatting variant creates a new person.

The second question is whether you are deduplicating the person or the company. In B2B, three colleagues from the same account may submit the same form; all three are genuinely different people, but they should hang off one deal. To make that distinction you need to know how records split apart; a duplicate rule built without settling how contacts, companies and deals relate in a CRM data model will happily overwrite the second legitimate colleague with the first.

The most durable setup is a priority chain rather than a single key: check the email match first, fall back to a normalised phone number, and open a new contact only if neither matches. CRM field mapping is decisive here, because matching runs through whichever CRM field a form field was mapped to. Map the email input to a free-text note and the filter will match nothing at all — there is no data where it is looking.

Merge, update or ignore: which behaviour is right?

When a match is found you have three options, and all three are legitimate. The failure mode is not knowing which one you chose.

Merge. The new submission is written as another touch under the existing contact and no second record opens. The history stays in one place, so a rep who sees that the same person downloaded a price sheet and later asked for a demo can read both side by side. This is the sensible default for most scenarios.

Update. Fields from the new submission are written over the existing record. Phone numbers change, job titles change. It keeps data fresh, but used carelessly it lets an empty field wipe out a filled one.

Ignore. The submission is logged but nothing in the CRM changes. This only makes sense for technical repeats — byte-identical submissions seconds apart. Applied to long-range repeats, it means quietly discarding a real enquiry.

If you are turning the filter on late and already have a tangled list, do not fix it record by record. Applying the same rule once across history with bulk edits and bulk actions and then leaving the form correctly configured costs a fraction of the time.

Which fields get overwritten and which stay protected?

This is where merging actually gets argued about. "Newer data is always better" is false: on the second submission the visitor may have typed only a name and an email and left the budget field blank. Letting that blank erase the budget captured earlier does not improve data quality, it destroys it. The table below gives a practical default per field type.

Field type	Example	Default behaviour	Reason
Identity key	Email, phone	Keep, store the new one as an alternate	Changing the key breaks past matches
Mutable profile	Job title, company, city	Update if filled, skip if blank	Newer profile data is usually more current
Commercial intent	Budget, need, quantity	Never overwrite, append as a new touch	Two requests must be readable separately
Attribution	UTM source, campaign	Keep the first, log the latest alongside	First touch and last touch answer different questions
Free text	Message, notes	Never overwrite, append below	Overwriting sentences is pure information loss

Writing this table once ends most of the later arguments. The same logic applies between systems: if the form feeds the CRM and the CRM feeds something else, decide upfront which side owns which field. Working through an ERP and CRM integration asks you the same question again, this time per system rather than per record.

Does a duplicate filter replace spam protection?

No. They answer different questions and neither substitutes for the other. Spam protection asks whether a submission came from a real human. A duplicate filter asks whether that real human is already on file. Trying to stop bot traffic with deduplication catches nothing, because bots generate a fresh address every time.

In Form Builder the two layers sit apart. The bot trap and rate limit uses an invisible honeypot field plus a per-IP submission cap to cut automated traffic at the door. Spam protection then drops any submission whose reCAPTCHA v3 score falls below the threshold into the spam bucket, and no lead is created from it. The duplicate filter only runs on what survives both — submissions already accepted as genuine. The order matters: authenticity first, uniqueness second.

There is one non-filter way to reduce repeats: make the form shorter and adapt it to the person. A visitor facing twenty fields at once is far more likely to abandon and start over. Using conditional logic to change the question based on the answer removes irrelevant fields entirely, and with them a share of abandonment-driven repeat submissions.

What does merging change about ownership and follow-up?

Collapsing two records into one does more than shorten a list; it settles ownership. With two records, two reps call the same person, both claim it, and the buyer receives two different quotes. With one record the owner is unambiguous, the second submission lands on the same card, and whoever owns that card sees the new request.

Routing is the thing to watch. Routing rules assign each submission to the right rep or team by service, region or budget. If the person picked a different service the second time, the rule will point at a different rep. Merging must not swallow that signal: the new request should notify the relevant team without silently reassigning the record. Ownership transfer is a decision, not an automatic side effect.

Writing that decision down also closes one of the most common marketing–sales arguments: the grey zone between "that lead never reached us" and "that was an old lead anyway." When you are aligning both teams around an SLA, the definition of a duplicate belongs in that document too, because the numbers move with it.

What is your duplicate rate actually telling you?

A duplicate filter is a measurement instrument as much as a cleanup tool. The number of repeats it catches says something about the form. When the rate jumps, the list of causes is short: the thank-you screen is not showing, the form got slow, the same campaign reached the same audience through two channels, or a list was mailed twice.

Submission tracking shows views, submissions and conversion rate on one panel, while the source and device breakdown splits that by UTM source, campaign, referring site and device type. If repeats cluster on mobile, the cause usually sits in form length or in the post-submit feedback. If a change needs reverting, version history stores every saved form configuration, so you can inspect the difference and roll back in one click.

One caveat: the definition of "a lead" moves with the duplicate rule. The day you switch the filter on, the count drops — nothing was lost, the counting simply got honest. To stop that drop from causing alarm, the definition has to be shared; keeping a metric dictionary so everyone reads the same number the same way makes that week considerably calmer.

What changes on the personal-data side when records merge?

Merging means combining personal data from two records under a single identity, which changes how you process it. The consent given in the first submission may not cover the same scope as the second. A practical rule: do not merge consents — apply the narrowest one, and keep both recorded against their own submission. That way you can answer "why did we email this person?" per submission rather than per contact.

Retention is part of the same picture. Retention and anonymisation lets you set a lifespan for submission data; when it expires, personal fields are anonymised automatically while the numeric statistics remain. On a merged record it must be clear which submission the clock started from — normally each submission counts from its own date, and merging does not restart anything.

Registry obligations belong here too. Where you must declare what you collect, for what purpose and for how long, your form fields and retention period have to match that declaration. The write-up on who has to register with the data controller registry and how frames that side. Data leaving the form should look the same as the inventory says it does.

In what order should the form be configured before launch?

Order matters, because each step makes the next one work. Map the fields to CRM fields first — without mapping, the duplicate filter has nowhere to look. Then write the key priority and the phone normalisation rule. Then decide the action on match and the field-level overwrite policy. Put the bot trap, the rate limit and the reCAPTCHA threshold in front of all of it.

Then run a real test: submit twice with your own email, twice with different phone formats, and once as a completely new identity. If the result differs from what you expected, the fault is rarely in the filter — it is usually in the field mapping. If a campaign is coming, use form load testing to put the form under concurrent submissions before launch; you will see, by measurement rather than guesswork, how the repeat rate climbs once response times stretch and the thank-you screen lags. Organisations with intake peaks feel this most sharply: at an education provider running admissions through a CRM, the same parent may submit three times in one day.

Once configured, one thing stays on the review list: the spam bucket. Check for false positives between the filter and the spam layer during the first week, then let it become routine. If you want to watch this end to end on your own form, open a Rocketly account and send two test submissions to see them merge into one contact the same day.

FAQ

Does the duplicate filter delete the second submission?

No. It stays as a submission record; only the second CRM contact is not created. Its content sits under the same person, so the campaign it came from and the message it carried are not lost.

What happens if two colleagues from one company submit the form?

With email or phone as the key they open as separate contacts, and that is correct. If you want them tied together, the link is made at company level, not contact level.

How long should the matching window be?

A few minutes covers technical repeats. For identity repeats, having no window at all is usually right — the same email is the same person six months later. If you need campaign-scoped counting, put the window in the reporting, not in the merge.

If I enable the filter later, do old records merge too?

No. The form-side filter applies to submissions from that point on. Existing clutter is a separate cleanup job, handled once with bulk actions.