In this guide
- Begin with a written definition of a successful lead
- Where can the hand-off fail?
- The 11 acceptance tests
- A worked example: one Dubai service enquiry, four possible outcomes
- Standard Web-to-Lead or a custom integration?
- What to ask your implementation team for before launch
- Frequently asked questions
- Need the website and CRM to agree?
A visitor can submit a website form, see a thank-you page and still leave your sales team without a usable enquiry. The form may not create a Salesforce Lead, the new record may reach the wrong owner, a validation rule may reject a field, or the campaign source may never make it into the CRM.
What to test: test the complete hand-off, not just the form button. For each realistic test enquiry, check the website response, the Salesforce Lead, ownership, duplicate handling, response email, source fields and the next sales action. A successful-looking browser screen is not proof that the hand-off is complete.
This guide is for a UAE business connecting a website to Salesforce, and for the developer, administrator or marketing team approving that connection. It covers the standard Salesforce Web-to-Lead form and points out where a custom integration may need a different test plan. It is not a claim that every Salesforce edition, configuration or region behaves identically.
Begin with a written definition of a successful lead
Before testing, agree what the business expects to happen. For a form called “Request a consultation”, an acceptable result might be: the enquiry appears once in the correct CRM place, has enough context to respond, is owned by the correct team, and has a traceable next action. Decide what a prospect sees if the request fails.
Separate three outcomes. Form submitted means the browser attempted to send data. Lead created means a record exists in Salesforce. Lead ready for action means the correct owner can see enough information to respond. These are not interchangeable events. Google Analytics recommends generate_lead for lead-generation actions, but your implementation still needs a truthful trigger and separate CRM-side validation; a click alone is not a completed CRM lead. Source: Google Analytics recommended events.
A practical acceptance record should contain a test-case ID, entry URL, submitted non-personal test values, Salesforce record reference (when one exists), owner, source fields, expected result, actual result, evidence link and disposition. Do not populate test records with real customer details.
Where can the hand-off fail?
A standard generated Web-to-Lead form sends the fields selected in Salesforce setup. The administrator controls required fields, validation, assignment and response settings. Salesforce says field validation runs before a Lead is created, so the record can be absent even when the business believes the website form was submitted. Source: Salesforce considerations for generating leads.
The diagram is deliberately simple. Behind each arrow sit settings that must be tested in the actual target Salesforce organisation rather than assumed from a demo.
The 11 acceptance tests
The following table is an implementation checklist, not a universal Salesforce configuration. Use an approved sandbox or test workflow, and record the observed outcome for every case.
| Check | Test | Acceptance evidence |
|---|---|---|
| 1. Record creation | Send one valid test enquiry | Find one Lead and compare its field values with the submitted test case. |
| 2. Required fields and validation | Omit a required value; then violate an approved rule | Check the rejection, administrator evidence and visitor-facing outcome. |
| 3. Owner and fallback | Submit different routing values and one unmatched case | Verify the user or queue and documented fallback. |
| 4. Duplicates | Repeat an existing test email or phone combination | Observe the configured allow, flag or block policy; do not presume a merge. |
| 5. Campaign context | Arrive through a tagged test URL and navigate to the form | Confirm only the intentionally captured and mapped source fields. |
| 6. Response email | Submit a case eligible for an acknowledgement | Verify the approved message and investigate failed delivery separately. |
| 7. Bot protection | Test the required challenge and an incomplete challenge | Confirm protection, accessible fallback and actual v2 compatibility. |
| 8. Capacity | Review documented limits and failure handling | Use an administrator-approved capacity plan; do not flood production. |
| 9. Error and recovery | Safely simulate a failed transfer | Find the error, owner and controlled retry without uncontrolled duplicates. |
| 10. Mobile and accessibility | Use phone, keyboard and appropriate assistive checks | Confirm labels, errors, focus order and final state. |
| 11. Conversion and reporting | Convert an approved sample Lead | Verify needed field mappings and distinguish clicks from qualified outcomes. |
1. Prove the Salesforce Lead was created
Open the actual Lead record and compare its values with the test case. Keep the generated Salesforce Lead ID or other permitted internal reference in your test sheet. A thank-you redirect is useful for the visitor; it does not replace the administrator's verification of the record.
If the record is missing, check the generated form, required fields, Web-to-Lead settings, validation and duplicate rules. Salesforce also documents State/Country picklist mismatches and unique-field conflicts. Keep protections in place while investigating; do not deactivate organisation-wide duplicate rules merely to make a test pass. Salesforce’s documented creation errors.
2. Check the Lead object requirements, not just visible form fields
Business teams sometimes simplify a form to three inputs while the CRM has additional mandatory fields or validation requirements. That difference can make a form appear polished but unreliable. Record which values are supplied visibly, which are set safely by the integration, and which are populated later by an approved process.
Salesforce's Web-to-Lead guidance says validation rules apply before a record can be created. The administrator should also confirm edition-specific setup permissions and any changes to the Lead object. Do not bypass production validation rules as a permanent fix merely to make the website form submit. Source: Salesforce Web-to-Lead setup.
3. Confirm the owner or queue and a fallback
“Lead created” is not the same as “someone will answer”. Test a straightforward lead, one needing specialist handling, and one that matches no routing condition. Check both the assigned owner and the queue or notification process that makes it visible to the team.
Salesforce's guidelines say web-generated leads can use an active lead assignment rule; if the rule is inactive, web leads go to the configured default owner. The business should choose its fallback deliberately, with staffing and coverage in mind. Source: Salesforce Web-to-Lead guidelines.
4. Decide what counts as a duplicate
A repeat website enquiry is not necessarily spam. It may be a returning prospect asking for a new service, or a customer entering updated details. Agree whether a repeat should create another Lead, flag a possible duplicate, or pass through an authenticated integration that updates a permitted existing record.
Salesforce uses matching rules to identify possible duplicates and duplicate rules to determine what happens when a match occurs. Actual outcomes depend on the configuration, so do not promise that a standard HTML form will automatically merge or update an existing Lead. Source: Salesforce Trailhead, duplicate management.
5. Preserve the campaign context without inventing attribution
A source field showing “Website” may be technically correct but not useful to a marketing team comparing different campaigns. If the business needs source, medium or campaign detail, define CRM fields, an allowed capture mechanism and the consent rules before deployment. Then test the exact journey from the landing URL through any internal pages to the submitted record.
For example, start with https://example.com/service/?utm_source=google&utm_medium=cpc&utm_campaign=consultation_test. On a test site, visit another page and submit the form. The expected values in the agreed Salesforce fields are google, cpc and consultation_test only if that capture and mapping were intentionally implemented. Salesforce does not populate custom website attribution fields just because the URL contains UTMs. Keep names, emails and phone numbers out of tracking URLs, and apply the site's consent and retention rules.
Avoid presenting hidden fields as a security mechanism. Client-side values can be changed; sensitive routing and commercial decisions should not trust an unauthenticated browser field alone.
6. Test the response email without implying delivery is guaranteed
Salesforce supports a default response template and configurable response rules. Check what the customer should receive, whether the template is approved, how sender identity is handled and what happens when the message is not delivered. A CRM record may be created even when the email is delayed or filtered. Source: Salesforce Web-to-Lead setup.
Use test addresses you control. Do not send messages to real prospects while approving a staging form.
7. Verify reCAPTCHA compatibility and accessibility
A technical detail matters here: Salesforce Help's 6 July 2026 article says standard Web-to-Lead/Web-to-Case integration supports Google reCAPTCHA v2, not v3. If the team assumes its existing v3 integration can be dropped into the generated Web-to-Lead form, the implementation plan may be wrong. Confirm the exact form type and region before choosing the protection. Source: Salesforce reCAPTCHA compatibility, 6 July 2026.
Also test the visitor's experience using a keyboard and mobile screen, and provide an accessible route for genuine users who cannot complete a challenge. When temporarily isolating CAPTCHA during diagnosis, do so only in controlled testing; do not leave the public production form exposed.
8. Respect the Web-to-Lead request limit
Salesforce documents a standard limit of 500 Web-to-Lead requests per day. Its help pages describe notifications to the default Lead Creator, and a pending-request queue for overflow with its own constraints. The precise handling of excess requests is not a safe reason to assume instant creation. A business with high volume, heavy bot traffic or time-critical response requirements should plan capacity and escalation with its Salesforce administrator. Source: Salesforce limits · Source: Salesforce pending requests.
Do not load-test a production Web-to-Lead endpoint by submitting hundreds of fictitious records. Use a controlled plan that respects the organisation's environment and limits.
9. Test an honest error and recovery path
A customer should not see “We received your enquiry” if the form has no evidence of success. On a direct Web-to-Lead form, the website may have limited visibility into the Salesforce-side outcome. A custom server-side integration can add authenticated status handling, internal logging and retry controls, but then the business must operate those components responsibly.
If losing enquiries would be unacceptable, decide up front how failures will be detected, who receives an alert, how a submission will be reconciled and how duplicates are prevented during a retry. Store the minimum information needed, protect access, and set deletion rules. Do not build an unprotected queue of personal data on a public server.
10. Test on the devices people actually use
Open the form at phone widths, on a normal desktop browser and through keyboard navigation. Check label-to-input association, error text placement, logical tab order, mandatory consent copy, and whether the final confirmation makes sense without relying only on colour. If your landing page includes an embedded third-party form, test it under the real domain and privacy settings—not just in the builder preview.
11. Confirm the data remains useful after Lead conversion
Choose which fields are still needed when a Lead becomes an Account, Contact or Opportunity. Salesforce documents the distinction between standard lead-field handling and administrator-configured mappings for custom fields during conversion. Check reporting requirements and mapping in the actual organisation rather than presuming every custom UTM or service field follows the Lead automatically. Source: Salesforce Lead FAQs.
For campaign reporting, compare lead attempts, Salesforce Leads created, sales-ready Leads, and qualified outcomes. A website event is useful measurement, but it should not be described as a signed customer or a valid routed enquiry without supporting evidence.
A worked example: one Dubai service enquiry, four possible outcomes
Imagine a Dubai professional-services business connecting a consultation form to Salesforce. These are fictional test scenarios, not UVs client records or results.
The visitor selects “Permit coordination”, enters a controlled test address, and arrives from a consultation_test campaign. The intended owner is the specialist queue for that service. The expected acknowledgement is a neutral “request received” email, not a promise of approval or a service date.
| Scenario | Browser result | Salesforce check | Acceptance verdict |
|---|---|---|---|
| A. Normal enquiry | Thank-you displayed | One Lead, correct queue and source | Pass only if both website and CRM agree |
| B. Unsupported service value | Browser tries to submit | Rule rejects record; no usable Lead | Fail unless the visitor and team receive a reliable error path |
| C. Returning prospect | Thank-you displayed | Duplicate created or flagged according to configured policy | Pass only when outcome matches documented policy |
| D. Campaign field missing | Thank-you displayed | Lead exists but campaign is empty | Sales hand-off may pass; attribution requirement fails |
Notice how Scenario D is neither a total failure nor a complete success. Treating it as “all green” hides a measurement problem, but treating it as “no enquiry” would also be misleading. This separation of business outcomes is why test matrices are more useful than only checking whether a form is clickable.
Standard Web-to-Lead or a custom integration?
For a small straightforward website with predictable fields, Salesforce's generated Web-to-Lead form can be an appropriate starting point. It has documented setup, standard response options and a known request limit. You still need routing, validation, spam-protection and reconciliation tests.
A custom server-side integration may be worth scoping when requirements include authenticated updates to existing records, controlled duplicate handling across Leads and Contacts, complex routing, durable failure queues, specific status acknowledgements or other systems in the workflow. That route introduces API authentication, security, monitoring and maintenance responsibilities. It is not automatically better simply because it contains more code.
Decision rule: choose the simplest integration that can demonstrate the required business outcomes, failure handling and access controls under realistic test conditions.
What to ask your implementation team for before launch
Ask for one signed-off test sheet that includes the scenarios above, screenshots or record IDs from an approved environment, the rules used to decide ownership, the response-email behaviour, the consent/retention approach, a rollback contact, and the person who will monitor submissions after launch. Keep account identifiers, credentials, test customer details and debug information out of public documents.
Our existing guide to mapping an enquiry before CRM automation explains the business process. This Salesforce checklist adds the platform-specific acceptance gates. For broader implementation questions, see Salesforce development or CRM solutions.
Frequently asked questions
Why is Salesforce Web-to-Lead not creating a Lead?
Check form setup, required fields, validation and duplicate rules, CAPTCHA and any State/Country dependencies. Investigate in an approved test environment. A thank-you redirect is not proof that a Lead was created. Salesforce’s creation-error guide.
Does Salesforce automatically remove duplicate website Leads?
No universal automatic outcome can be promised. Matching and duplicate rules are configurable, and a custom integration may implement additional logic. Test a repeat enquiry and confirm the result matches your policy before launch.
Can Web-to-Lead use reCAPTCHA v3?
Salesforce's 6 July 2026 compatibility article says its Web-to-Lead/Web-to-Case framework supports reCAPTCHA v2, not v3. Check the current official guidance for the exact form type before implementing bot protection.
How many Web-to-Lead requests can Salesforce receive?
Salesforce documents a standard 500 requests per day limit and describes overflow handling. If higher volume or bot traffic is realistic, review capacity with your Salesforce administrator before launch; do not rely on unverified instant processing.
Should a GA4 lead event fire when the button is clicked?
A button click is not necessarily a generated lead. Choose a trigger that matches your form's confirmed success state, and report CRM-created and qualified leads separately when the business needs those outcomes. See Google's recommended lead events.
Need the website and CRM to agree?
UVs Digital Hub works across website development, CRM systems and Salesforce implementation. Share the form requirements, Salesforce configuration assumptions and the evidence you already have; we can help scope a practical review without promising a result before seeing the setup. Discuss the requirement.
Editorial source note (checked 30 October 2026): Primary sources are linked alongside the relevant claims above. This is an implementation checklist, not a Salesforce certification, implementation testimonial, data-protection opinion or confirmation of a production integration. Salesforce is a trademark of Salesforce, Inc. UVs Digital Hub does not claim a Salesforce partner designation.