Prevent Duplicate Salesforce Leads from Gravity Forms

Duplicate Salesforce leads can come from several parts of a Gravity Forms integration. Two feeds may match the same submission, or a manual resend may create another lead after a scheduled job has already sent the entry. Checking only the current feed settings can miss that history. In an investigation involving overlapping feeds and partial entries, I traced the events for each form entry and compared the Salesforce IDs they produced. The fixes addressed two separate problems: make the feed conditions select the intended route, and reuse the saved Salesforce ID when later events process the same entry.

Compare integration logs for each entry

Configuration shows what should happen now; retained integration logs show what actually happened before. I grouped log rows by form entry and compared the Salesforce record IDs, feed IDs, timestamps, and normalized identity fields. That revealed entries with two or three distinct leads when one was expected.

This distinction mattered because some feeds had been edited after the incidents. I separated confirmed current behavior, confirmed historical behavior, latent risk, and configurations with no duplicate evidence. That prevented one explanation from being stretched across every form.

Make feed conditions mutually exclusive

One form had two keyless create feeds. A blank branch in the first feed’s OR condition overlapped the condition for a second feed. The same submission legitimately matched both rules, and each rule created a lead one second apart.

The fix was not a fuzzy CRM lookup. It was to make the routing conditions mutually exclusive and verify the actual submission categories. When two feeds represent different business destinations, their predicates should be tested so exactly one feed matches each supported case.

Keep the Salesforce ID through later events

Partial-entry and abandonment features turn one form entry into a sequence. A visitor can save progress, an operator can resend, a scheduled job can detect abandonment, and a later completion can run the normal feed. Without durable state, each event looks like a fresh opportunity to create.

I changed the integration to preserve the authoritative Salesforce record across that lifecycle. Later pages and retries update the existing record instead of creating a new one. The important part is that identity lives with the entry, not inside the request that happened to run first.

Apply the same rules to manual resends

Admin resend buttons are useful during support, but they cannot be a separate universe. A manual push should inspect the same stored record identity and follow the same create-or-update rules as the scheduled scanner.

I also made the operator-facing result explicit. “Sent” is not enough; the system should say whether it created, updated, skipped, or failed, and which durable record it used.

Test partial entries, retries, and completion

1. Submit a complete entry that matches exactly one feed.
2. Save a partial entry with the minimum mapped identity.
3. Run the abandonment job twice.
4. Manually resend before and after abandonment.
5. Complete a previously partial entry.
6. Confirm every later action targets the same CRM record.

I tested later result pages as well as the first page. Pagination and query limits can hide old entries or cause scanners to revisit the wrong slice.

Separate retry protection from lead deduplication

Duplicate leads split notes, trigger repeated outreach, distort attribution, and make staff doubt the integration. Cleanup also carries risk because the wrong merge can erase the true history.

Make repeated processing safe by retaining the entry identity and remote record ID. Keep routing conditions separate, show the outcome of each action, and replay events in different orders during testing.

Why a broad dedupe search was not enough. It would have been easy to search Salesforce for a matching email before every create. That can suppress some duplicates, but it introduces new ambiguity: families can share contact details, fields may be incomplete during a partial entry, and two requests can still race between search and creation. A fuzzy lookup also hides the configuration error that made two feeds run.

I used the form entry as the durable workflow identity and preserved the remote record ID once one existed. Business rules still decide whether a new submission represents a new lead, but later events in the same entry lifecycle no longer make that decision again. For routes that truly need cross-entry deduplication, I would define an explicit CRM identity policy and enforce it with an atomic server-side mechanism where possible. Idempotency and deduplication are related but different: the first makes retries of one operation safe; the second decides whether two apparently different operations represent the same person or opportunity.

Trace the complete form entry history

For a duplicate-lead report, collect the entry ID, feed IDs, Salesforce record IDs, and event times before changing settings. Check whether multiple feeds matched, then replay the partial-entry, resend, scheduled, and completion paths in a test environment. Each later action for the same entry should use its saved Salesforce record unless an explicit business rule requires another one. Confirm that behavior in both the integration logs and Salesforce before considering the issue resolved.

Photo by cottonbro studio on Pexels.