Duplicate rules are one of the first things a careful Salesforce admin turns on, and for good reason: duplicate leads split activity history, confuse ownership and inflate pipeline reports. But the same rule that politely warns a rep about a duplicate can quietly stop a web form from creating a lead at all. The visitor fills in the form, the lead never appears, and the only trace is an email to one user that nobody may be reading. This post covers why it happens, how to tell whether it is happening to you, and the fixes Salesforce itself recommends.
Why an "alert" turns into a block
A duplicate rule pairs a matching rule (which fields decide that two records are the same) with an action: block the save, or allow it with an alert, with a report, or both. "Allow and Alert" sounds harmless, because a person can read the warning and click through.
Web-to-lead has no person to click. Salesforce's Help article on the issue puts it directly: web-to-lead "operates as an automated process and cannot display the duplicate alert dialog to a user for confirmation." The result, per the same article, is that duplicate rules set to Allow and Alert can block web-to-lead submissions. The submitted lead is not created. A rule designed to inform a rep becomes, on the web channel, a gate that turns returning prospects away.
The prospects most likely to match an existing lead are often the ones you most want: people who already downloaded something, came back, and are now raising their hand.
How you find out: one email, to one user
The failure is not shown to the visitor in any useful way, and it does not land in a report. Salesforce documents that a failed web-to-lead submission produces an email with the message "Salesforce could not create this lead because of the reason listed below." That email goes to the Default Lead Creator named in your web-to-lead settings, and it cannot be customized or redirected to a different recipient.
When the cause is a duplicate rule, the reason in that email is the familiar duplicate prompt, "Use one of these records?" If your Default Lead Creator is a former employee, an integration user or an alias nobody watches, those emails are the only record of the lost submissions, and they are going unread.
Duplicates are not the only cause
The same Help article lists several other reasons a web-to-lead submission can fail with that email, and they are worth checking in the same pass:
A state without a country. With state and country picklists in play, a form that sends a state but no country fails with "A country must be specified before specifying a state value."
A unique field. A Lead field marked unique rejects a second submission carrying the same value.
A lead-converting trigger. An Apex trigger that converts leads on insert can conflict with web-to-lead creation.
Web-to-lead switched off. If the feature has been disabled for the org, every submission fails, and the form keeps accepting entries regardless.
The fixes Salesforce recommends
1. Exempt the web-to-lead user from the alerting rule. Add a condition to the existing duplicate rule so it does not run when the current user is your Default Lead Creator. Reps keep their warning; the form stops being blocked.
2. Give web leads their own "Allow and Report" rule. Salesforce's suggested alternative is a separate rule for the web-to-lead user with the action set to Allow and Report, without the alert. Duplicate leads from the form are created and logged for review instead of being refused. This keeps the record and leaves the cleanup to a person, which is the right order for a lead someone just asked to be contacted about.
3. Do not simply deactivate the standard rules. Turning off the Standard Lead Matching Rule also stops the failures, but Salesforce notes it removes that duplicate protection for the whole org, not just the web channel. It trades one problem for another.
4. Filter spam at the form. The same article recommends CAPTCHA or reCAPTCHA on public forms. Bots that resubmit the same details are a common source of duplicate matches, and they also spend the daily web-to-lead budget, which we covered in the 500-a-day web-to-lead cap.
Salesforce also notes that in some cases records may not be blocked even when rule criteria are met, so test with a known duplicate in a sandbox rather than assuming either outcome.
A ten-minute check
1. Find your Default Lead Creator in the web-to-lead settings, and confirm a person reads that mailbox. Search it for "could not create this lead."
2. List active Lead duplicate rules and note any set to alert. Each one is a candidate for the exemption or the separate reporting rule above.
3. Submit a test duplicate through the live form, using details that match an existing lead, and confirm a record is created.
4. Compare counts. Form submissions logged in your analytics or form tool against leads created by the web-to-lead user, by day. A persistent gap means submissions are being lost somewhere between the two.
The takeaway
Duplicate rules are worth having. The mistake is configuring them for the rep at a keyboard and forgetting the form that has no one behind it. A small exception for the web-to-lead user, a monitored Default Lead Creator inbox and one test submission keep data hygiene from costing you the prospects who came back. Once leads are arriving reliably, our guides to capturing UTM parameters in web-to-lead forms and lead tracking across multiple product lines cover what to do with them.
Sources: Salesforce Help, Salesforce Duplicate Matching Rules Blocking Web-to-Lead Submissions; Salesforce Help, Error "Salesforce Could Not Create This Lead" on Web-to-Lead Form Submission.