A Gravity Forms submission can be marked spam after one integration has already created a CRM contact, spreadsheet row, PDF, signature request, Slack message, webhook job, or custom database record. Replaying every feed after restoration can duplicate outreach, analytics, documents, tasks, and billable actions. Stable external IDs must be reconciled first.
Use this for forms connected to several add-ons or custom integrations, especially when feeds run asynchronously or third-party systems retry independently. The audit should use pseudonymous IDs and system references instead of exporting complete entry content.
Quick answer
Build a ledger with the Gravity Forms entry ID, form ID, submission ID or correlation ID, each feed, external system, deterministic lookup key, provider record ID, prior attempt, and observed state. Query every destination before replay. Mark each feed skip, link existing, repair, replay, or escalate, then use idempotency keys and record the returned external ID during recovery.
What to check first
- Inventory active and recently disabled feeds, custom hooks, background jobs, webhooks, notifications, payment actions, CRM, spreadsheets, documents, signatures, chat, analytics, and server-side tracking.
- Find stable identifiers already sent with the original attempt, such as entry ID, submission UUID, transaction ID, hashed correlation ID, webhook event ID, or deterministic external key.
- Search each destination by its approved stable key, then use time, form, source, and masked contact context only when the primary key is absent.
- Classify each integration as never attempted, failed before create, created and linked, created but unlinked, ambiguous, retried, completed, reversed, or safe to replay.
- Write the external ID and recovery action back to protected entry notes or an incident ledger so later staff and retries make the same decision.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Inventory every downstream path | Inventory active and recently disabled feeds, custom hooks, background jobs, webhooks, notifications, payment actions, CRM, spreadsheets, documents, signatures, chat, analytics, and server-side tracking. | Every active downstream integration has one observed state and owner. |
| Recover stable lookup keys | Find stable identifiers already sent with the original attempt, such as entry ID, submission UUID, transaction ID, hashed correlation ID, webhook event ID, or deterministic external key. | Existing external records are linked rather than recreated. |
| Query destinations before replay | Search each destination by its approved stable key, then use time, form, source, and masked contact context only when the primary key is absent. | Replayed feeds use stable idempotency or a documented duplicate control. |
| Assign one action per feed | Classify each integration as never attempted, failed before create, created and linked, created but unlinked, ambiguous, retried, completed, reversed, or safe to replay. | WordPress entry notes and the recovery ledger contain external IDs and final outcomes. |
Why this usually happens
- Gravity Forms, background queues, and external systems do not share one transaction boundary.
- A timeout can hide a successful remote create.
- An add-on may store its external ID only after a callback that never reached WordPress.
- Manual staff work can create an external record while the entry remains in spam.
- Email, chat, analytics, and document feeds can duplicate impact even when no payment is involved.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
entry_id,feed,external_system,lookup_key,external_id,state,action
22104,crm,hubspot,gf:22104,contact-8841,created,link_existing
22104,webhook,erp,event:gf-22104,,timeout_unknown,escalate
22104,spreadsheet,ops_sheet,gf:22104,row-991,created,skip
22104,notification,site_mailer,gf:22104,msg-219,delivered,skip
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Inventory every downstream path
- Recover stable lookup keys
- Query destinations before replay
- Assign one action per feed
- Record external IDs and idempotent recovery results
Decision rule
Replay only when the destination proves no equivalent record or side effect exists and the feed supports a controlled idempotency key. Link or repair an existing record when identity is clear. Escalate ambiguity instead of using another create as a discovery method.
What to tell the client or owner
Give the integration owner a ledger of feeds, lookup method, observed state, external ID, duplicate consequence, approved action, and result. Redact personal content and secrets while preserving stable pseudonymous identifiers.
Production verification checklist
- Every active downstream integration has one observed state and owner.
- Existing external records are linked rather than recreated.
- Replayed feeds use stable idempotency or a documented duplicate control.
- WordPress entry notes and the recovery ledger contain external IDs and final outcomes.
Mistakes to avoid
- Do not replay all feeds because the Gravity Forms entry was restored.
- Do not treat a timeout as proof that the destination created nothing.
- Do not search external systems using broad personal-data exports.
- Do not leave successful external IDs only in a private support message.
Questions teams ask during testing
What if the original feed sent no external ID back?
Use approved deterministic keys and provider search, then classify the result as found, absent, or ambiguous. Do not create another record merely to learn what happened.
Are notifications part of deduplication?
Yes. Duplicate customer or staff email, chat, and tasks can be harmful even when the underlying CRM or payment record is unique.
When HandL WP should help
Bring in HandL WP when the issue affects a production site, paid lead flow, checkout, email delivery, or a managed fleet. We can preserve evidence, isolate the failing layer, make the smallest corrective change, and verify the result across WordPress, the external service, logs, and the user journey.
If this is active on a production site, audit Gravity Forms feed recovery.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references