A visitor completes a form on your website.

The page displays a success message.

Nobody receives the lead.

The submission may still exist inside the form plugin. It may have reached an automation platform and failed later. The CRM may have rejected it, merged it with an existing contact, placed it in the wrong pipeline, or created a record without assigning it to anyone.

A website form and a CRM rarely communicate through one simple step.

The complete workflow may involve:

• The website
• The form platform
• Custom code
• An API or webhook
• Zapier, Make, or another automation platform
• The CRM
• Assignment rules
• Internal notifications
• Customer confirmations
• GA4
• Google Ads
• Other third-party systems

The fastest way to diagnose the problem is to follow one identifiable test submission through the entire process.

A successful form message only confirms part of the workflow

Most forms display a success message after the website accepts the submission.

That usually confirms that:

• The browser sent the request
• The website accepted the data
• Basic validation passed
• The front-end form received a successful response

It may not confirm that:

• The form entry was saved
• The integration ran
• The CRM accepted the data
• A contact was created
• A deal or opportunity was created
• The lead was assigned
• Staff received a notification
• The visitor received a confirmation
• Analytics recorded the event
• Google Ads received the conversion

This is why testing only the visible website form can be misleading.

The later steps often fail quietly.

Start by confirming whether the form saved the submission

The first question is simple:

Does the original form system contain the submission?

Depending on the website, this may be stored in:

• WordPress
• Gravity Forms
• Contact Form 7 with an entry-storage plugin
• WPForms
• HubSpot
• Jotform
• Typeform
• Shopify
• A booking platform
• A custom database
• An external form service

If the submission is missing from the form system, the failure likely occurred on the website or during the original request.

Possible causes include:

• JavaScript errors
• Validation problems
• Spam filtering
• Security rules
• Caching conflicts
• Failed background requests
• Server errors
• Incorrect conditional logic
• Browser-specific issues
• A third-party embed that did not load correctly

If the form system contains the entry, the investigation can move to the next handoff.

Check whether the integration actually ran

A saved form entry does not guarantee that the CRM integration started.

Many form platforms use separate actions for:

• Saving the entry
• Sending an email
• Creating a CRM record
• Calling a webhook
• Triggering an automation
• Recording a conversion

One action can succeed while another fails.

Review:

• Form feeds
• Integration settings
• Conditional rules
• Webhook actions
• Automation history
• API logs
• Plugin logs
• Error messages
• Retry history
• Execution timestamps

Look for the exact test submission rather than relying on general dashboard status.

A green status indicator may only mean that the account connection is active.

It does not prove that a specific submission completed every step.

Conditional logic may be blocking the CRM action

Conditional logic is a common source of missing leads.

A form may only send data to the CRM when:

• A specific service is selected
• Consent is checked
• A lead meets a qualification rule
• A location is within the service area
• A certain answer is present
• The visitor chooses a particular form path
• The email address is not already known
• A hidden field contains the expected value

These conditions can become outdated after a form is edited.

For example:

• A dropdown label changes, but the integration still checks the old value
• A field is replaced, but the automation still references the original field ID
• A required hidden field stops populating
• A new service option is added without adding it to the routing logic
• A staging workflow is copied to production with different field values

The form can submit normally while the CRM action is skipped.

The website may be sending data to the wrong destination

The integration may run successfully and still send the lead somewhere nobody is checking.

Common destinations include:

• A test CRM account
• A sandbox environment
• An old pipeline
• A former agency’s Zapier account
• An inactive webhook
• A previous company division
• A discontinued automation
• A duplicate CRM portal
• A staging endpoint
• An old email distribution list

This often happens after:

• A website migration
• A CRM migration
• A staff departure
• A domain change
• A redesign
• An agency handoff
• A copied form
• A rebuilt landing page

Confirm the actual destination URL, account, portal, pipeline, and object being used.

Do not rely on the label shown inside the website dashboard.

An integration named “HubSpot Production” may still point to the wrong account.

Authentication may have expired or lost permission

CRM integrations often depend on:

• API keys
• OAuth connections
• Private app tokens
• Service accounts
• User-specific permissions
• Automation-platform credentials

These connections can fail after:

• A password change
• Multi-factor authentication changes
• A staff member leaves
• A user loses administrator access
• An app is removed
• A token expires
• A CRM permission model changes
• A vendor updates its authentication requirements

Some systems display a clear authentication error.

Others continue saving form entries while silently failing to send them anywhere else.

Check the integration history for:

• Unauthorized responses
• Expired tokens
• Revoked permissions
• Missing scopes
• Reconnection prompts
• Failed refresh attempts
• Account ownership problems

If the connection belongs to a former employee or previous vendor, transfer ownership before removing the old account.

The CRM may be rejecting the request

A website can send the request correctly and receive an error from the CRM.

Common reasons include:

• Missing required fields
• Invalid property names
• Incorrect dropdown values
• Invalid date formats
• Invalid phone formats
• Text sent to a number field
• Values exceeding field limits
• Missing owner IDs
• Invalid pipeline stages
• Unsupported object types
• Incorrect consent values
• Duplicate restrictions

The form and CRM may describe the same field differently.

For example:

A form can continue collecting valid information while the integration sends it in a format the CRM refuses.

The raw request and response are often more useful than the visible settings screen.

Field mappings may be outdated

Field mappings frequently break after someone edits the form.

Common changes include:

• Renaming a field
• Replacing a dropdown
• Deleting and recreating a field
• Changing field IDs
• Changing CRM properties
• Replacing one CRM object with another
• Updating required fields
• Adding new service options
• Changing internal values

The visible question may look unchanged to the visitor.

Behind the scenes, the integration may now be pointing to a field that no longer exists.

Review both:

• The human-readable field labels
• The internal field IDs or property names

Two fields can have the same visible label and completely different internal identifiers.

The CRM may update an existing contact instead of creating a new one

A missing lead may already exist in the CRM.

Many CRMs use email address, phone number, or another identifier to detect duplicates.

When a matching contact is found, the CRM may:

• Update the existing contact
• Merge the new data
• Ignore some incoming fields
• Preserve the existing owner
• Skip deal creation
• Skip workflow enrollment
• Keep the record in an old lifecycle stage

The website may report a successful integration even though no new contact appears.

Search for the test email address, phone number, form ID, or timestamp across the CRM.

Also review the existing record’s activity history.

The latest submission may be buried inside a contact that was created months earlier.

A contact may be created without a usable sales record

Some workflows create a contact but fail to create the next object.

Depending on the CRM, that might be:

• A lead
• A deal
• An opportunity
• A ticket
• A task
• An appointment
• A custom object

This can happen when:

• Deal creation is a separate workflow
• Required pipeline information is missing
• The contact does not meet enrollment conditions
• The workflow only runs for new contacts
• Duplicate handling prevents reenrollment
• A lifecycle stage is already too advanced
• The form submitted to the wrong object

The contact exists, but the sales team never sees it in the place where they manage new opportunities.

Trace the expected object creation separately from the original contact creation.

The lead may be in the CRM but assigned to nobody

A CRM can contain the lead and still fail operationally.

Common assignment problems include:

• An inactive owner
• A deleted user
• A broken round-robin rule
• Missing territory data
• An unsupported location
• An empty service field
• A workflow that excludes existing contacts
• A default owner who no longer monitors leads
• A queue nobody checks
• Assignment based on a field that stopped populating

Confirm:

• Who owns the record
• Which workflow assigned it
• Whether the expected routing rule ran
• Whether the owner is active
• Whether a task was created
• Whether the lead entered the correct pipeline or queue

A lead stored without ownership can remain unnoticed indefinitely.

Internal notifications may be failing

Sometimes the CRM workflow succeeds and the notification fails.

The team may assume the lead never arrived because nobody received an email or Slack alert.

Check:

• CRM notification history
• WordPress mail logs
• SMTP logs
• Email-delivery services
• Distribution groups
• Slack automation history
• Task creation
• Spam folders
• Quarantine
• Suppression lists
• Invalid recipients
• Disabled users
• Old email addresses

A notification email can also be sent successfully by the website and rejected later by the receiving mail system.

“Sent” and “delivered” are separate events.

Spam filters may be blocking valid leads

Spam protection can prevent valid submissions from reaching later systems.

This may involve:

• Google reCAPTCHA
• Cloudflare Turnstile
• Akismet
• Form-level spam filtering
• Web application firewalls
• CRM spam rules
• Email security tools
• Hidden honeypot fields
• Rate limiting

False positives are more likely when:

• The visitor uses a VPN
• Several submissions come from one office
• The form contains links
• The message includes unusual formatting
• The visitor uses a role-based email address
• The website recently changed domains
• A campaign generates a sudden increase in submissions
• Test entries use repeated information

Review rejected, spammed, or quarantined entries before assuming the integration failed.

Webhooks can fail without a visible website error

A webhook sends data from one system to another through an HTTP request.

The website may submit normally even when the webhook receives:

• A 400 invalid request response
• A 401 authentication error
• A 403 permission error
• A 404 endpoint error
• A 422 validation error
• A 429 rate-limit response
• A 500 server error
• A timeout

Useful webhook evidence includes:

• Request timestamp
• Destination URL
• Request headers
• Payload
• Response code
• Response body
• Retry history
• Execution duration

Without this information, the dashboard may only show “failed” or “completed.”

A completed automation can still produce the wrong business result if the next system accepted the request but processed it differently than expected.

Automation platforms may hide the real failure

Zapier, Make, and similar tools often sit between the website and CRM.

A workflow may fail because:

• One step was turned off
• A connection expired
• The account reached a task limit
• A filter rejected the submission
• A router sent it down the wrong path
• A field returned an unexpected value
• A later step failed after the CRM contact was created
• The automation was edited but never published
• The workflow only runs for new records
• Error notifications go to an old account

Review the execution history for the exact test submission.

Compare a failed run with a known successful run.

The difference is often one field, condition, or response.

Custom code may be handling more than the dashboard shows

A standard form plugin may only be the visible entry point.

Custom code may:

• Change the submitted values
• Add hidden fields
• Route leads by location
• Send data to several systems
• Create CRM records
• Trigger internal notifications
• Prevent duplicate submissions
• Record attribution
• Modify the confirmation
• Stop the default integration from running

This code may live in:

• The theme
• A child theme
• A custom plugin
• A code-snippet plugin
• A must-use plugin
• A server-side script
• A tag-management container
• An automation platform

Do not replace or reconnect the visible integration until you understand whether custom code depends on it.

Two integrations may also be sending the same lead, which can create duplicate or conflicting records.

Embedded forms require a different investigation

Some websites embed forms hosted by:

• HubSpot
• Jotform
• Typeform
• Calendly
• Rezgo
• A CRM
• A booking platform
• A payment provider

The visible form appears on the website, but the submission may happen inside the third-party platform.

That affects:

• Where the original entry is stored
• Which system owns validation
• Whether the website can see the result
• How conversions are tracked
• Whether cross-domain tracking is required
• Whether the CRM integration occurs before or after the embed returns control

Check the embedded platform before troubleshooting the website’s native form tools.

The website may only contain the embed code.

The lead may be reaching the CRM while tracking reports nothing

CRM delivery and conversion tracking should be tested separately.

A real lead may reach the sales team while:

• GA4 records no event
• Google Ads imports the wrong conversion
• The event fires on the form button rather than a successful submission
• The thank-you page is never reached
• An embedded form does not communicate with the main site
• Cross-domain tracking is missing
• Consent settings block advertising tags
• Duplicate tags fire twice
• The CRM conversion import is delayed
• A test conversion action is marked as primary

The reverse can also happen.

Google Ads may record a conversion even though the CRM never received a usable lead.

Always compare measurement with the real business outcome.

A practical way to test the complete workflow

Use one test submission with information that is easy to identify.

For example:

• A unique email address
• A distinct first and last name
• A specific test message
• A recorded submission time
• A known service selection
• A phone number reserved for testing

Then document each step.

1. Submit the form

Record:

• Page URL
• Date and time
• Browser
• Device
• Form values
• Confirmation shown

2. Confirm the original entry

Check whether the form platform saved it.

Record:

• Entry ID
• Timestamp
• Status
• Spam classification
• Form actions triggered

3. Check the integration

Review:

• Feed status
• Webhook request
• Automation run
• Payload
• Response
• Error messages

4. Search the CRM

Look for:

• Contact
• Lead
• Deal
• Opportunity
• Ticket
• Task
• Duplicate record
• Existing contact update

5. Review routing

Confirm:

• Owner
• Pipeline
• Stage
• Queue
• Territory
• Assignment workflow

6. Check notifications

Verify:

• Internal email
• Customer confirmation
• CRM task
• Slack alert
• Follow-up automation

7. Check measurement

Confirm:

• GA4 event
• Google Ads conversion
• Meta event
• Attribution fields
• Thank-you-page visit

This turns a vague report about “missing leads” into a list of confirmed and unconfirmed steps.

Compare a failed lead with a successful lead

When some leads arrive and others do not, compare them directly.

Look for differences in:

• Form answers
• Service selection
• Location
• Email domain
• Existing CRM status
• Consent
• Lead source
• Device
• Browser
• Submission time
• Hidden fields
• Owner
• Pipeline
• Spam score
• Automation path

A single condition may explain why one lead continued and another stopped.

This is usually more productive than repeatedly reconnecting every integration.

Common fixes

The correct repair depends on the confirmed failure point.

Possible fixes include:

• Reconnecting an expired CRM account
• Correcting field mappings
• Updating a webhook URL
• Replacing an invalid API token
• Adding required CRM fields
• Fixing conditional logic
• Correcting internal field values
• Updating assignment rules
• Repairing a notification
• Moving an automation into a business-owned account
• Adding error logging
• Adding retry handling
• Separating production and test workflows
• Updating cross-domain tracking
• Correcting the primary Google Ads conversion
• Rebuilding one unstable integration

A durable fix should make the workflow easier to verify the next time something fails.

Add monitoring where the business depends on the workflow

Many lead workflows fail silently because nobody checks them until sales volume appears low.

Useful monitoring may include:

• Alerts for failed webhooks
• Automation error notifications
• CRM reports for unassigned leads
• Daily submission counts
• Form-to-CRM reconciliation
• Email-delivery logging
• Test submissions on a schedule
• Alerts when no leads arrive during an expected period
• Conversion comparisons between the website and CRM

The goal is to detect the failure before a prospect or advertising report exposes it.

When several vendors are involved

Form-to-CRM problems often cross company boundaries.

The website provider may say the form works.

The CRM provider may say the account is active.

The automation platform may show a completed run.

The email provider may report no outage.

Each statement can be accurate.

Someone still needs to follow one lead through the entire workflow and determine what happened at every handoff.

That is especially important when no single vendor has access to all of the systems involved.

When a focused assessment makes sense

A focused technical assessment can help when:

• Leads are disappearing
• The failure is inconsistent
• Several systems are involved
• Vendors disagree about responsibility
• The workflow is undocumented
• The business is preparing to increase advertising spend
• Previous repairs did not hold
• Tracking and CRM data do not match
• Nobody can confirm the full process
• You need evidence before approving implementation work

Kismet’s Website Lead Workflow Assessment traces one primary lead path through the website, integration, CRM, routing, notifications, and conversion tracking.

The assessment costs $500 and includes:

• Workflow mapping
• Controlled test submissions
• Review of the connected systems
• Identification of the last confirmed successful step
• Written findings
• Recommended next steps
• A review call

Implementation is separate.

You can use the findings with Kismet, your internal team, or another qualified provider.

—

Find out where the lead stopped

If website submissions are missing, delayed, routed incorrectly, or absent from your CRM, Kismet can trace one complete lead workflow and document what happened.

Website Lead Workflow Assessment: $500

Request a Lead Workflow Assessment

—

Written by Joey Zuccarini
COO at Kismet Creative Co.