Gravity Forms can process eligible non-payment feeds when a valid entry is marked Not Spam and can send feedback to compatible anti-spam services. It does not automatically process payment feeds or notifications. A generic recovery instruction such as replay all feeds can create duplicate CRM records, repeated webhooks, duplicate subscriptions, or charges. Each installed add-on and custom hook needs a documented capability and reconciliation rule.
Use this for sites with CRM, email marketing, webhooks, Zapier, Slack, PDFs, user registration, posts, payments, custom feeds, and notifications. Build the matrix before support restores a real lead so the decision is not made under pressure.
Quick answer
Inventory every installed feed, notification, custom hook, and external destination for the affected form. For each row, document whether Mark Not Spam processes it automatically, whether the action is payment-related, its deduplication key, how to query destination state, whether manual replay exists, and who can approve it. Restore one synthetic entry and compare observed behavior with the matrix.
What to check first
- List form feeds, conditional logic, add-on versions, payment status dependencies, notifications, custom gform hooks, anti-spam services, and external destinations.
- Classify each action as eligible automatic non-payment feed, excluded payment feed, excluded notification, anti-spam feedback, custom unknown, or no side effect.
- Define a stable destination lookup key such as entry ID, transaction ID, external ID, idempotency key, email plus timestamp, or document number.
- Mark a synthetic entry Not Spam while logging feed execution, destination queries, notifications, payment hooks, retries, and resulting external identifiers.
- Compare automatic observations with documentation and code, then write manual recovery and approval steps only for unresolved required actions.
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 action | List form feeds, conditional logic, add-on versions, payment status dependencies, notifications, custom gform hooks, anti-spam services, and external destinations. | Every feed, notification, payment path, and custom hook has one matrix row. |
| Classify documented recovery behavior | Classify each action as eligible automatic non-payment feed, excluded payment feed, excluded notification, anti-spam feedback, custom unknown, or no side effect. | Automatic non-payment feeds match observed synthetic behavior. |
| Define destination lookup keys | Define a stable destination lookup key such as entry ID, transaction ID, external ID, idempotency key, email plus timestamp, or document number. | Payment and notification actions remain blocked until separately approved. |
| Observe one synthetic restoration | Mark a synthetic entry Not Spam while logging feed execution, destination queries, notifications, payment hooks, retries, and resulting external identifiers. | Destination IDs and deduplication outcomes are stored with the recovery case. |
Why this usually happens
- Different Gravity Forms add-ons implement feed processing and recovery contracts differently.
- Payment feeds are intentionally excluded from blind automatic recovery because financial state needs reconciliation.
- Notifications are separate from feed processing and may contain stale or security-sensitive content.
- A timeout can leave an external record even when WordPress recorded a failure.
- Custom hooks may run on entry status changes outside the standard add-on feed framework.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
form_id: 61
entry_id: synthetic-22104
capability_matrix:
crm_feed: automatic_non_payment
webhook_feed: automatic_non_payment
stripe_feed: manual_payment_reconciliation
admin_notification: manual_message_decision
recaptcha_feedback: compatible_service_feedback
custom_pdf_hook: code_review_required
duplicate_records: 0
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 action
- Classify documented recovery behavior
- Define destination lookup keys
- Observe one synthetic restoration
- Write approved manual steps for the remaining gaps
Decision rule
Allow automatic behavior only where the installed add-on contract and synthetic evidence agree. Reconcile payment providers, notification delivery, and unknown custom hooks separately. Never replay an ambiguous external action without querying its destination first.
What to tell the client or owner
Give the site owner the affected version, exact workflow, observed result, business impact, evidence location, temporary control, named owner, and next review time. Remove credentials and personal data from shared screenshots and logs.
Production verification checklist
- Every feed, notification, payment path, and custom hook has one matrix row.
- Automatic non-payment feeds match observed synthetic behavior.
- Payment and notification actions remain blocked until separately approved.
- Destination IDs and deduplication outcomes are stored with the recovery case.
Mistakes to avoid
- Do not label every Gravity Forms integration a feed and assume equal behavior.
- Do not click Mark Not Spam before inventorying custom hooks.
- Do not use a live card or customer address in the synthetic test.
- Do not replay a timeout without a destination lookup.
Questions teams ask during testing
Does Mark Not Spam resend notifications?
No. Notifications need a separate decision based on prior delivery, current content, recipients, and business need.
Does it rerun payment feeds?
No. Payment recovery requires provider reconciliation and an approved manual path to avoid duplicate charges or subscriptions.
When HandL WP should help
Bring in HandL WP when this 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, build a Gravity Forms recovery matrix.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references