Clean lead capture in Salesforce comes from choosing one intake path per form type and configuring it deliberately. Native Web-to-Lead suits simple, low-volume forms. Account Engagement forms or form handlers suit teams that nurture and score. API or middleware integrations suit high volume and custom websites. Whichever path you choose, add bot protection, standardized fields, hidden source fields, duplicate checks and failure alerts before the form goes live.
Which paths can carry website leads into Salesforce?
There are five common paths, and most companies use two or three at once. The problems start when nobody knows which form uses which path.
- Native Web-to-Lead: Salesforce generates basic HTML that posts straight into the Lead object. No marketing tool is involved.
- Account Engagement forms and form handlers: hosted forms, or your own forms posting into Account Engagement, which then syncs prospects to Salesforce.
- Marketing Cloud Engagement: landing pages and forms that feed data extensions and journeys, with records reaching Sales Cloud through its connector.
- Website platform integrations: your CMS or form builder sends submissions through the Salesforce API, directly or via middleware.
- Chat and meeting-booking tools: conversational and scheduling apps that create or update leads when a visitor books time or chats.
Write the inventory down first. List every form, the page it lives on, the path it uses and the person who owns it. Orphaned forms are a frequent source of junk records.
| Capture method | Best for | What you need to configure | Common failure |
|---|---|---|---|
| Native Web-to-Lead | Simple contact forms at modest volume | Default lead creator, reCAPTCHA, hidden fields, response rules, assignment rules | Silent overflow past the daily cap, or blocked submissions nobody reads about |
| Account Engagement form | Teams that score, grade and nurture prospects | Fields, completion actions, connector sync, progressive profiling | Prospect never syncs because it has not met the sync criteria |
| Account Engagement form handler | Keeping an existing site form while tracking activity | Field mapping, external spam protection, success and error redirects | No built-in bot check, so spam floods the prospect list |
| Marketing Cloud Engagement | Consumer brands running large email journeys | Data extensions, connector, rules for when a subscriber becomes a lead | Records stay in marketing data and never reach sales |
| API or middleware | High volume, custom sites, multi-step logic | Integration user, upsert keys, error queue, retry logic | Errors logged in a tool nobody monitors |
| Chat or booking tool | Visitors ready to talk now | Field mapping, matching to existing records, owner logic | Creates a second lead for someone already in the CRM |
When does native Web-to-Lead fit, and where does it fall short?
It fits simple forms where you need a lead record and an auto-reply, nothing more. It falls short on volume, validation and visibility into failures.
Salesforce documents a daily cap on web-generated leads, currently 500 requests in a 24-hour period. Requests over the cap go to a pending queue shared with Web-to-Case. Confirm current limits with Salesforce support if you run paid campaigns that spike traffic.
The generated HTML does no validation of its own. Required-field checks and email format checks must be added to the form code or the page. Treat that HTML as a starting point for your web developer, not a finished form.
Web-to-Lead does support some useful extras. You can pass a Campaign ID to add the lead as a campaign member. You can also set a lead record type and use response rules to pick the auto-reply template.
How do Account Engagement forms and form handlers differ?
Hosted forms live inside Account Engagement and give you more control. Form handlers let you keep your own form while still sending the data into Account Engagement.
Hosted forms include built-in bot protection and progressive profiling, and they report form views and errors. Form handlers lack built-in bot protection, so spam control falls to your website. Salesforce advises against pairing a form handler with Web-to-Lead when completion actions also assign prospects, because both paths can create records.
Remember that a form fill creates a prospect first. It only becomes a Salesforce lead once your connector settings allow it to sync, which often waits for assignment or a score threshold.
How do we keep bots and spam out of Salesforce?
Layer several cheap defenses rather than relying on one. Each catches a different kind of junk.
- reCAPTCHA in Web-to-Lead: it is on by default in current setup. Check it is still enabled and supported in the regions you sell to.
- Honeypot fields: a hidden input that people never see. If it arrives filled in, drop the submission before it reaches Salesforce.
- Server-side validation: check email format, block obviously fake domains and reject values like test or asdf.
- Rate limits at the website or middleware layer to stop bursts from one source.
- Lead validation rules for the last line of defense. A failed rule stops the record, so keep these narrow.
Spam also uses up your daily Web-to-Lead allowance. A bot attack can push real prospects into the pending queue, or past it entirely.
How do we stop form fills from creating duplicates?
Decide what should happen when a submitter already exists as a lead or contact, then configure matching to match that decision. The default behavior often surprises people.
Duplicate rules on leads can compare new submissions against existing leads and contacts. For Web-to-Lead, a matching rule set to alert can block the submission outright. That happens because no user is present to dismiss the warning.
Salesforce suggests two fixes. Exclude the default lead creator from the alerting rule, or add a separate report-only rule for that user. Then flag matches for review rather than losing the form fill.
For existing customers, many teams log the submission as a campaign member or task on the contact instead of creating a new lead. Our duplicate data cleanup guide covers merge logic and rule tuning in depth.
How do we capture UTM parameters and lead source reliably?
Store the campaign parameters in hidden form fields and write them to dedicated lead fields. Then lock the Lead Source picklist so values cannot drift.
A small script on your website reads utm_source, utm_medium, utm_campaign and similar values from the landing URL. It keeps them in a cookie or session storage and fills the hidden fields at submission. Without the storage step, values vanish when the visitor clicks to a second page.
Keep two sets of fields: first touch and most recent touch. First-touch values should never be overwritten once set. Most-recent values update on every new form fill. How those touches roll into campaign credit belongs in your attribution model, which our campaign attribution guide covers.
Govern the Lead Source picklist like a controlled vocabulary. Keep it short, map each UTM medium to one value with Flow, and remove free-text entry. Review new values quarterly with marketing and sales together.
Which fields should be required, and how do we standardize them?
Require only what routing and follow-up need on day one. Collect the rest later through progressive profiling or enrichment.
Shorter forms usually convert better and invite fewer fake answers. A common minimum is name, business email, company and country, plus a consent checkbox where required. Account Engagement progressive profiling can ask additional questions on later visits instead of the first one.
Standardize values at the point of entry:
- State and country picklists: once enabled, form submissions must match valid picklist values. Test your form values against them, and confirm how your capture path sends codes versus names.
- Picklists over free text for industry, company size and product interest.
- Phone formatting to one pattern, ideally with a country code captured separately.
- Email verification through a validation service on high-volume forms, called before the record is created.
Every mismatch here becomes a routing problem later. A lead with Calif. in the state field may never reach the West territory queue.
How should consent be captured on lead forms?
Capture consent explicitly at the moment of the form fill and store when and how it was given. None of this is legal advice; have counsel approve the wording.
Use an unchecked opt-in box where your markets require one, and map it to a dedicated field. Also store the consent date, the form name and the wording version shown. Salesforce consent objects such as Contact Point Type Consent can hold this in more detail. Our data privacy guide explains those design choices.
What happens after the form is submitted?
Two things should fire immediately: a confirmation to the prospect and assignment to an owner. Both are easy to configure and easy to break.
Web-to-Lead response rules choose an auto-reply template based on lead values, and assignment rules set the owner. Check the default lead creator user, because it owns leads when no other rule applies. That user needs specific permissions, so a deactivated or changed user can break intake. Routing logic beyond the basics is covered in our lead routing guide.
How do we test forms and catch failures after launch?
Test every form end to end before launch, then review failure signals on a fixed schedule. Broken forms are often discovered only when a salesperson asks where the leads went.
- Submit test entries covering each country, each product interest and each consent state.
- Confirm the record, owner, campaign membership, source fields and auto-reply for each test.
- Use the Web-to-Lead debug option during testing so Salesforce emails the debugging details.
- Route the default lead creator's mailbox to a monitored shared inbox. Failed creations arrive there as error notification emails, so make sure someone reads that inbox.
- For API and middleware paths, alert on error counts, not just outages.
- Build a daily report of leads by form and source, and investigate any form that drops to zero.
Which of our projects involved lead capture?
Two projects in our case studies centered on getting cleaner leads into Salesforce. Both used Sales Cloud with Marketing Cloud Account Engagement.
Before the project, leads at a commercial real-estate firm were not captured automatically. We set up website form capture with routing by location and service type, and a Google Analytics connector for automatic UTM capture and first-touch attribution. The firm says it finally trusted its lead-source data.
An aircraft-engine MRO company had captured leads from 14 trade shows by hand, and half its records were duplicated. We built QR-code landing pages and forms for trade-show capture and routing. Prospect sync included duplicate detection, and manual entry was eliminated.
What should a phase-one lead capture project include?
Phase one should fix the forms that produce most of your leads and set up the monitoring that keeps them working. Leave redesigns and new tools for later.
- An inventory of every form, its capture path and its owner.
- One chosen path per form type, with retired paths switched off.
- Bot protection and honeypots on every public form.
- Duplicate rule settings that flag rather than silently drop matching submissions.
- Hidden UTM fields, first and latest touch fields, and a governed Lead Source picklist.
- Standardized required fields and state and country values.
- Consent fields with date and source.
- End-to-end tests, a monitored failure inbox and a daily intake report.
With those in place, scoring, routing and attribution work from records you can trust.
