Connecting WordPress Forms to Your CRM Without Losing Leads

A visitor fills in your contact form, sees the thank-you message and waits. The inquiry never reaches the CRM, because an API token expired last Tuesday and nothing told anyone. Sales does not know the lead exists, and the site reports a successful submission.

This is the normal way a WordPress forms CRM integration fails: quietly. Setting one up takes an afternoon. Making sure every submission arrives, or that somebody is told when one does not, takes a little more thought.

Where leads go missing

In the integrations we are asked to repair, the lead was nearly always lost at one of these points:

• the CRM rejected the record because a required field was empty or a dropdown value did not match,
• the credentials expired or were revoked when a staff member left,
• the CRM's API was briefly unavailable and nothing retried,
• the form plugin kept no copy, so there was nothing to resend,
• a duplicate rule in the CRM silently discarded a returning contact,
• someone renamed a form field or a CRM property and the mapping broke.

Make the website keep its own copy

The form's entry in the WordPress database is your safety net. If the CRM handoff fails, the entry is what you resend from. Check first that entries are being stored at all.

Gravity Forms stores every entry by default. Contact Form 7 does not store submissions anywhere unless you add a storage plugin such as Flamingo. The free version of WPForms does not keep entries in your database either. If your form only sends an email, a mail delivery problem and a CRM problem on the same day mean the inquiry is gone. Notification emails are a useful second channel, not a record. We cover the email side in WordPress not sending emails.

Three ways to connect: add-on, webhook or middleware

	Native add-on	Webhook or custom code	Middleware service
What it is	An extension from the form plugin's vendor for one named CRM	The site posts the entry to the CRM's API	A service such as Zapier, Make or n8n sits between form and CRM
Flexibility	Limited to what the add-on exposes	Complete	Good for branching and multi-step flows
Failure visibility	Varies. Look for entry notes and a log	As good as you build it	Run history in the service's dashboard, outside WordPress
Ongoing cost	Usually part of a plugin license tier	Maintenance time	Subscription, typically tied to task volume
Best when	One mainstream CRM, standard objects	Custom objects, deduplication rules, high volume	Several tools need the same lead and nobody on the team writes code

Start with the native add-on if one exists for your CRM. Its vendor tracks the CRM's API changes, and for a simple contact form it is all you need. Move to custom code when the add-on cannot do something specific: search before creating, write to a custom object, or attach the lead to an existing company.

Middleware suits small teams, with two cautions. Every submission passes through a third company's servers, which belongs in your privacy documentation. And failures show up in a dashboard nobody opens, so route its alerts to a shared inbox or chat channel.

Map the fields on paper first

List the properties a new lead must have in the CRM, with their types and allowed values, and put each form field beside its destination. The mismatches appear straight away:

• Required properties that the form does not collect. Add the field, or send a fixed default.
• Dropdowns and picklists. The form's option values must match the CRM's internal values exactly. Labels can differ, values cannot.
• Names. One "Your name" box against separate first and last name properties. Use a name field with two inputs.
• Owner and status. Decide who owns a web lead and what status it gets, and set both in the integration.

Also send the form name and the URL of the page it was submitted from, so sales can see where the lead came from.

Decide what happens when the person already exists

Some submissions come from people already in your CRM: customers with a new question, leads returning after six months. An integration that always creates a record fills the database with duplicates. One that blindly updates can overwrite a salesperson's corrections with whatever the visitor typed.

The dependable pattern is search, then decide:

1. Look up the email address in the CRM.
2. If there is no match, create the contact or lead with all mapped fields.
3. If there is a match, update only fields that are empty in the CRM, and never change the owner or the original source.
4. In both cases, add the new message as a note or task on the record, so the owner sees that this person has been in touch again.

Check how your CRM's own duplicate rules treat API requests. Some block the request with an error, which your integration must log, and some merge without telling you.

Log every attempt and retry the failures

Every send should leave a trace on the entry: sent, or failed with the reason. With Gravity Forms, a custom integration can hook into the gform_after_submission action, which runs once the entry has been saved, and record the outcome as entry meta:

add_action( 'gform_after_submission_5', 'wwc_send_lead_to_crm', 10, 2 );

function wwc_send_lead_to_crm( $entry, $form ) {
    $response = wp_remote_post( 'https://crm.example.com/api/leads', array(
        'timeout' => 10,
        'headers' => array(
            'Authorization' => 'Bearer ' . CRM_API_TOKEN,
            'Content-Type'  => 'application/json',
        ),
        'body'    => wp_json_encode( array(
            'email'      => rgar( $entry, '2' ),
            'first_name' => rgar( $entry, '1.3' ),
            'last_name'  => rgar( $entry, '1.6' ),
            'page_url'   => rgar( $entry, 'source_url' ),
        ) ),
    ) );

    $code = is_wp_error( $response ) ? 0 : wp_remote_retrieve_response_code( $response );

    if ( $code >= 200 && $code < 300 ) {
        gform_update_meta( $entry['id'], 'crm_status', 'sent' );
        return;
    }

    $error = is_wp_error( $response ) ? $response->get_error_message() : wp_remote_retrieve_body( $response );
    gform_update_meta( $entry['id'], 'crm_status', 'failed' );
    gform_update_meta( $entry['id'], 'crm_error', $error );
}

The form ID, field IDs and endpoint are placeholders, and the token belongs in a constant in wp-config.php. What matters is the short timeout, the check on the response code, and the status saved either way. The wp_remote_post function returns an error object when the connection itself fails, so both cases are handled.

Then build on that status:

• Retry. A scheduled task picks up entries marked failed and tries again with increasing gaps, up to a limit. Action Scheduler, the job queue library that ships with WooCommerce, fits well, and WP-Cron is enough on smaller sites.
• Send in the background on busy forms, so a slow CRM does not hold up the visitor's confirmation page.
• Alert. When an entry runs out of retries, email a named person with the entry link and the error text.
• Reconcile. Once a week, compare the count of entries with the count of web leads created in the CRM.

With a native add-on, find the equivalent. Gravity Forms add-ons generally leave a note on the entry, and detailed logs can be switched on under Forms > Settings > Logging. Turn logging off after troubleshooting, since the log files contain submitted data. For the general principles, see designing integrations that survive third-party API failures.

Carry consent and attribution with the lead

Consent. If the form has a marketing opt-in, the CRM needs the answer, when it was given and the wording the person agreed to. Map the checkbox to the CRM's subscription fields and send the timestamp. An unticked box must arrive as "no", not as an empty value. What you must record depends on the laws that apply to you, so confirm the detail with your own counsel.

Attribution. Add hidden fields for utm_source, utm_medium, utm_campaign, the ad click ID if you run paid search, the landing page and the referrer. Most form plugins can fill a hidden field from a URL parameter. In Gravity Forms it is the "Allow field to be populated dynamically" setting.

Two things break this in practice. Visitors rarely submit on the page they landed on, so the parameters have left the URL by the time they reach the form. And page caches often serve the same stored HTML whatever the UTM parameters are, so server-side population gets nothing. The fix for both is a small script that saves the parameters in a first-party cookie on arrival and writes them into the hidden fields when a form loads.

Test a WordPress forms CRM integration before you trust it

1. Submit with every optional field empty.
2. Submit with an email address that already exists in the CRM.
3. Submit with accents, an apostrophe and an emoji in the message.
4. Break the credentials on a staging copy and submit. Confirm the entry is marked failed, the alert arrives, and the retry delivers it once the token is restored.
5. Submit from a page reached with UTM parameters, after browsing two other pages first.
6. Check that spam caught by your honeypot or CAPTCHA is not sent to the CRM at all.

Doing it yourself or handing it over

One form, one mainstream CRM and a native add-on is a job most site owners can do themselves. Get a developer involved when you need search-before-create logic, custom objects, retries and alerting, or when several forms feed several systems. That is everyday work for our WordPress form development team, including Gravity Forms integrations and broader WordPress API integrations.

Frequently asked questions

Do I need a paid plugin to send WordPress form entries to a CRM?

Not always. Many CRMs offer their own WordPress plugin or an embeddable form, and a developer can connect almost any form plugin through its hooks. Paid form plugins add entry storage and official add-ons, which make the connection easier to keep reliable.

Should I just embed the CRM's own form instead?

It is the simplest route and removes the integration entirely. The trade-offs are less control over design and validation, a dependency on the CRM's script, and no copy of the submission on your site. For a single newsletter form it is often fine.

How do I know if leads were lost in the past?

Export form entries for a period and compare the email addresses with contacts created in the CRM over the same dates. Any address present on the site and absent from the CRM was lost, and the entry still holds what you need to follow up.