When a form lead seems missing, first determine whether the submission was never stored, was stored but not notified, or was attached to an existing CRM contact. Repeated testing can create duplicate contacts and make the investigation harder, so use one controlled submission at a time.
Open the published page in a private window and submit a clearly labeled test, such as TEST, 30 Oct, 10:15 UTC. Use an email address and phone number you are authorized to use. Record the page URL, form name, exact time and time zone, fields entered, and the confirmation shown. Take a screenshot. Do not use a real client’s information for troubleshooting.
If the form shows an error, stop there and send the details to support. If it shows success, continue by checking the source of truth rather than relying only on an email alert.
In HighLevel, go to Sites → Forms → Submissions, select the correct form, and search the relevant date range. HighLevel’s submissions page lets authorized users expand an individual entry, manage visible columns, and export submissions as CSV.[1] Also check Contacts for the test email and phone. The form may have updated an existing contact instead of creating a new one.
If the record exists but nobody received an alert, the form captured the data; the likely issue is downstream notification or automation. Check spam and quarantine folders, then have an administrator review the notification recipient, workflow enrollment, sender configuration, and execution logs. Do not keep submitting the form to test an email problem.
If no stored submission exists, confirm that you tested the published page, not a builder preview, and that the correct form is embedded. Note whether the form is native HighLevel, WordPress/plugin-based, or an external embed. Browser console errors, consent requirements, ad blockers, or a broken embed may affect submission, but clients should not edit scripts or disable security controls. Escalate with the evidence collected.
HighLevel’s Contact Deduplication Preferences determine whether matching form and integration submissions create a separate contact or update an existing one. When Allow Duplicate Contacts is off, HighLevel can match using the configured primary and optional secondary field, email or phone, and update the existing contact. When it is on, matching submissions may create separate records.[2]
Before changing this setting, discuss the business rule with the CRM owner. Two family members may share a phone, a person may use different emails, and some organizations intentionally keep separate records. A change can affect forms, Zapier, and social-message sources, so it is not a casual troubleshooting toggle.
Administrators can use Contacts → Manage Duplicates to find possible matches by email, phone, or name, or manually select known duplicates. Review every candidate and select the record with the most accurate, current history as the master. HighLevel warns that a completed contact merge cannot be reversed; conflicting values, custom fields, appointments, payments, and active workflow behavior should be reviewed before confirmation.[3]
Do not merge based on name alone. Compare email, normalized phone number, company, address, conversations, opportunities, tags, consent status, and recent activity. Export or otherwise preserve required data under your organization’s policy before a large cleanup. If you lack admin access, send the duplicate record links to an administrator instead of attempting workarounds.
Include the published page URL, form name, test time and time zone, test email/phone, screenshot of the confirmation or error, whether the entry appears under Form Submissions, whether a contact exists, whether an alert arrived, and links to any duplicates. Never send passwords, full payment information, or unrelated client records.
This evidence tells support whether to investigate capture, contact matching, notifications, workflow execution, or the embed itself.