Forms, Surveys and Funnels: Where Leads Actually Leak

The first leaks are usually inside the capture path: a visible field is tied to the wrong CRM field, required data is optional, or conditional logic sends a valid lead down the wrong branch. Next come broken post-submit journeys, unpublished or misfiltered workflows, and reused forms changed without checking every placement. The final audit step is tracking, because page-level conversion code on the form page can count page loads as leads even when nobody submits.

1. The form collects an answer, but the CRM does not receive usable data

A form can look correct and still produce an incomplete contact record. The label the visitor sees is not proof that the input is linked to the CRM field expected by workflows, assignments or personalization.

HighLevel forms need to use standard contact fields or correctly linked contact custom fields. Standard fields include First Name, Last Name, Email, Phone and Message. When a new lead submits a HighLevel form, the platform creates a contact record, but downstream work still fails when the intended field was not actually selected or linked.

The audit starts at Sites → Forms → open the form → Submissions. Submit the live form rather than relying on the builder preview, then adjust the visible submission columns to expose every value that should have been captured. After that, open Add Object Fields in the builder and inspect the underlying field selected for each visible input. Labels, field order and styling are not enough.

Custom fields created directly in the Form and Survey Builder deserve extra attention. HighLevel lets builders set the custom field name and unique key before saving, but both become locked in the builder after the form is saved. Later corrections must be made in the Custom Fields section. This is why a polished label can sit on top of an old or unexpected CRM key.

There is also a hardcoded naming issue: custom fields containing the word score are treated as numeric scoring elements across forms, surveys and quizzes. A field using “score” for a nonnumeric concept should be renamed rather than treated as an ordinary text or selection input.

Field architecture should be settled before forms are spread across a funnel. The conventions in Custom Fields and Tagging Conventions You Won't Regret in a Year provide a structure for avoiding duplicate fields and ambiguous keys.

2. A submission exists, but it lacks the data required downstream

Required-field validation and workflow completeness checks solve different problems. Marking an input as required stops a visitor from submitting that form without the value. A workflow condition decides what should happen when a submission still lacks information needed for a later action.

Compare three things directly:

1. The fields marked required in the form or survey builder.
2. The values visible in the submission record.
3. The fields required by every assignment, qualification, notification and personalization step after submission.

If phone is needed for assignment but is not required, the form is doing exactly what it was configured to do when it accepts an email-only lead. If a workflow message expects First Name but the submission contains no First Name, the workflow has received an incomplete input rather than a failed submission.

HighLevel separates required fields from workflow-level handling of incomplete data. Use form requirements for information that must be supplied before submission. Use workflow conditions to alert staff or skip actions when a dependency is missing.

Do not diagnose this leak by checking only whether a contact was created. The correct test is whether the contact contains every field needed by the next step and whether the workflow follows the intended incomplete-data path when one of those values is absent.

3. The submit button works, but the visitor goes nowhere useful

A successful submission does not automatically move someone to the next funnel step. The form’s post-submission setting must either display a confirmation message or redirect the visitor.

This creates a common split between CRM success and funnel failure. The submission appears under Sites → Forms, the contact exists, and the button visibly worked. The visitor still sees an inline message when the intended journey required a redirect to a qualification, scheduling or thank-you page.

Test both sides of the event. First, confirm that the submission record exists. Second, confirm that the visitor sees the expected message or reaches the exact destination page configured for that form. A successful database write does not prove that the funnel journey continued.

Conditional logic adds more routes to test. HighLevel form rules can show or hide fields, display different messages, redirect visitors or disqualify leads based on their answers. A single successful test path says nothing about the other branches.

Create a test matrix containing every answer that changes the outcome. For each branch, record which fields appear, whether required identity fields remain available, whether the lead is disqualified, and which message or URL follows submission. Rules that hide a required identity field or redirect to an old destination turn valid traffic into a silent funnel exit.

4. The lead reaches the CRM, but the workflow never starts

The native Form Submitted trigger fires from an actual submission through a form created inside HighLevel. The reliable setup path is Automation → Workflows → add Form Submitted trigger → set Form Is to the specific form → save → test → Publish.

Three configuration errors explain much of this leak: the workflow remains unpublished, the trigger points to an older form, or the workflow uses the wrong trigger. The page being live has no effect on whether an unpublished workflow runs.

Open the live page through the same route a visitor uses, submit the form, and inspect the form’s submission list first. If the record is present but the workflow did not run, inspect the trigger and publication state. If no submission record exists, return to the form itself rather than editing workflow actions.

Each submission can create a Form Submitted trigger event, including repeat submissions from the same person. Conditions or cooldown periods are therefore needed when duplicate follow-up should be suppressed. The opposite problem occurs when one workflow is intended to handle several forms but its filters include only one of them.

Filter to the exact form when the workflow belongs to one funnel. When a workflow intentionally covers several forms, add each accepted form to the trigger criteria and test every one separately.

5. A shared form was changed as though it belonged to one page

HighLevel forms are centralized assets. The same form can be selected through the Form Picker and reused across supported funnel and website builders. A change that appears local can therefore affect several campaigns.

Before changing fields, required settings, redirect behavior or notifications, create a placement list for the form. Record every funnel step and website page where it appears, then test each placement after the edit. A redirect suitable for one campaign can be wrong for another page using the same asset.

Custom-field cleanup carries a separate destructive risk. Removing a field from the form layout does not delete the underlying custom field. Deleting it through Settings → Custom Fields → Trash removes that field from every form, survey and contact where it was used. A cleanup intended for one lead form can therefore erase a dependency used elsewhere.

Do not use global deletion as a shortcut for decluttering a single form. Remove the field from that form’s canvas, identify every other asset and workflow that uses it, and delete the custom field globally only after those dependencies have been replaced.

This dependency mapping belongs early in a new account build. Building a GoHighLevel Sub-Account From Zero: The Order That Avoids Rework covers the broader sequence for establishing account components before duplicating assets.

6. The CRM has the value, but the next funnel page cannot display it

HighLevel saves custom-field values to browser local storage when the visitor enters them directly through a form, survey or order form. Backend updates made by workflows remain in the contact database but are not automatically written into that browser storage.

A backend-computed value requires custom logic that writes the value into local storage before the page attempts to display it.

7. The dashboard number is not the lead count being discussed

HighLevel’s native funnel-step opt-in metric is based on successful submissions, not form loads. In the funnel Stats tab, Opt-ins include form submissions, survey submissions and two-step order-form submissions. The documented calculation is Opt-in Rate = Opt-ins × 100 ÷ Unique Page Views.

This makes the funnel-step metric useful for checking whether a page containing a form block produced successful submissions. It does not mean every dashboard labeled Opt-in represents only lead-form submissions.

The broader Sites → Analytics Opt-in KPI combines several conversion types. HighLevel includes purchases, form or survey submissions, and appointment bookings in that measure. Before calling it a form conversion rate, set the asset type and specific asset filters. Otherwise, a purchase or booking can be discussed as though it came from the lead form.

Use the form’s Submissions area as the capture record, the workflow history as the follow-up record, and the correctly filtered analytics view as the reporting record. Compare the same asset and time period across all three. Mixing site-wide opt-ins with one form’s submissions produces a discrepancy that no form edit can fix.

The measurement trail should answer three separate questions: Was the form submitted? Did the expected workflow run? Did the chosen reporting view count that same event?

8. Tracking counts form-page loads as conversions

The final leak is often not missing leads at all. It is conversion code installed where it runs on the initial form page rather than after a successful submission.

HighLevel distinguishes site-wide tracking from page-level tracking. Base code belongs in the funnel or website settings under the head or body tracking area. Page-specific event code belongs in a page’s Header Tracking or Footer Tracking area when that event should run only on that page.

A browser conversion event placed in the form page’s Header Tracking area executes at page level. Because the code loads with that page, it can count a visit to the form as a conversion before the visitor submits anything. Traffic then appears to produce leads that do not exist in the form’s Submissions list.

For a funnel that redirects successful submissions to a dedicated confirmation page, place the conversion-event code on that confirmation page and keep the base tracking script site-wide. HighLevel specifically identifies page-level tracking as suitable for conversion or thank-you pages.

For Meta server-side reporting tied to the lead event, use a Form Submitted workflow trigger filtered to the specific form, followed by the Facebook Conversion API action with Event Type set to Funnel Event. This ties reporting to the actual form submission rather than the initial page load.

Also inspect both installation levels. The same script installed page-wide and funnel-wide can produce duplicate pageviews, events or conversions. Keep the base script site-wide and install only the event code on the page where that event should occur.

Cloning creates the opposite failure. HighLevel does not copy page-level tracking code when a funnel step or website page is cloned. The copied form can continue collecting leads while the external conversion event disappears. Inspect the cloned page’s Tracking Code area and determine whether the required base code already exists at site level before adding anything.

Do not use static View Page Source as the sole tracking test. HighLevel states that head and body tracking code can be injected client-side and therefore be absent from static source even while running. Use browser network tools or the reporting provider’s diagnostic tools. Adding a second copy because the first was not visible in static source turns a tracking check into duplicate conversion reporting.

The final reconciliation is simple: one completed form submission, one expected workflow event and one conversion event. A conversion recorded on page load, two conversions for one submission, or no conversion after a cloned-page submission identifies the tracking layer as the leak.

What to do

1. Submit the live form once and inspect Sites → Forms → open the form → Submissions before changing any workflow.
2. For every visible input, open Add Object Fields and verify the underlying standard or custom contact field rather than relying on its label.
3. Mark every field required by assignment, qualification or personalization as required in the form builder, then add a workflow condition for missing dependencies.
4. Set the post-submission behavior explicitly to either a confirmation message or the exact next-step URL, then test both the submission record and visitor destination.
5. Configure Automation → Workflows → Form Submitted → Form Is → the specific form, save the trigger, run one test submission and enable Publish.
6. Create a placement list for every reused form before changing its fields, required settings, redirect or notifications.
7. Before deleting a field through Settings → Custom Fields → Trash, identify every form, survey, contact and workflow that uses it.
8. Keep the base tracking script at funnel or website level and place conversion-event code only on the dedicated confirmation page.
9. After cloning a funnel step, inspect its page-level Tracking Code area because that code is not copied.
10. Reconcile one test submission against three records: one form submission, one workflow event and one conversion event.

Questions people ask

Why does the contact exist while the workflow has no value for a field?

The visible input can be tied to the wrong CRM field, or the intended contact custom field was never selected. Test the live form, expose the relevant columns in the form’s Submissions view, and inspect the underlying field through Add Object Fields.

Why did a valid submission stay on the same funnel page?

The form was configured to display a confirmation message instead of redirecting. Conditional logic can also replace the expected redirect with a message, another URL or a disqualification outcome.

Does a form submission always start its workflow?

No. The workflow must use the Form Submitted trigger, be filtered to the intended HighLevel form, be saved and be published. A live page does not activate an unpublished workflow.

Why is a value present on the contact but missing from the next page?

Backend workflow updates remain in the contact database but are not automatically written into browser local storage. Only custom-field values entered directly through a form, survey or order form are stored there for later funnel pages.

Does HighLevel count a form load as a native funnel opt-in?

No. HighLevel defines a funnel-step opt-in as a successful form, survey or two-step order-form submission. Separate browser conversion code placed on the form page can still fire on page load and create a false conversion in an external reporting system.

If the form, workflow and reporting numbers do not agree, the fix starts with one live submission traced from the field mapping through the final conversion event. We build it inside GoHighLevel, hand it over in full, and you own it. Book a 30-minute walkthrough.