Gravity Forms Versioning can store a revision successfully even when the email that announces the change fails later. Teams that use the notification inbox as their only audit record can miss real edits, while a blind retry can send duplicate or misleading messages after the revision already exists.
Use this when form changes require approval, client notice, regulated evidence, incident review, or reliable change alerts through Gravity SMTP or another mail connector.
Quick answer
Treat revision storage and notification delivery as two linked records. Make one marked form edit on staging, capture the version ID, checksum, author, UTC time, and diff, then trace the notification through WordPress, the SMTP plugin, provider, and inbox. Simulate a connector rejection and a lost provider response. Keep the revision as authoritative history, alert on notification failure, and retry by stable version ID so one revision produces no more than one accepted notice.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Connector rejects | Version 114 | Revision stored, failure visible |
| Lost response | Provider accepted | No duplicate message |
| Recipient fixed | Same version ID | One successful retry |
| Second edit | New checksum | New revision and notice |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
|---|
| Separate storage and delivery states | Record form ID, version ID, checksum, author, UTC time, changed objects, notification ID, recipient set, connector, provider response, and inbox result. | Every saved revision has an explicit notification state, even when no email was attempted. |
| Create one stable notification key | Simulate failure before message creation, before provider acceptance, after provider acceptance, and during status recording. | A lost response cannot create two provider-accepted messages for one version ID. |
| Trace provider acceptance | Compare the stored revision count and diff with WordPress mail hooks, SMTP event log, provider message ID, bounce state, and recipient inbox. | The email identifies the correct form, author, time, and revision without exposing sensitive values. |
| Retry only unresolved delivery | Test a manual retry, automatic retry, browser resave, two simultaneous editors, and a recipient correction without creating another form revision. | A later form edit creates a new checksum, revision ID, and independent notification record. |
What to check first
- Record form ID, version ID, checksum, author, UTC time, changed objects, notification ID, recipient set, connector, provider response, and inbox result.
- Simulate failure before message creation, before provider acceptance, after provider acceptance, and during status recording.
- Compare the stored revision count and diff with WordPress mail hooks, SMTP event log, provider message ID, bounce state, and recipient inbox.
- Test a manual retry, automatic retry, browser resave, two simultaneous editors, and a recipient correction without creating another form revision.
- Confirm alerts expose enough context to find the revision but never include form secrets, personal entry data, or mail credentials.
Field notes
- Write the pass condition before changing anything. A repeatable synthetic fixture makes the before and after comparison useful.
- Keep exact versions and UTC timestamps because scheduled jobs, caches, retries, and background processing can change the evidence.
- Check the public experience and the stored server-side result. Admin previews and isolated API calls do not prove the whole workflow.
- Repeat the test after the relevant cache, queue, scheduled action, webhook, and observation window has finished.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
revision_notice:
form_id: 18
version_id: 114
checksum: sha256-recorded-value
notification_key: form-18-version-114
smtp_state: failed_before_acceptance
retry_count: 1
Why this usually happens
- Database storage commits before an external mail provider returns a final response.
- The retry job lacks a stable version identifier and treats each attempt as a new event.
- A provider accepted the message but the site timed out before recording its ID.
- Teams check the inbox instead of the revision table when deciding whether a change happened.
Decision rule
The revision ledger remains the source of truth. Close delivery only when the exact version ID has one accepted provider message or a documented permanent failure with an owner.
Production verification checklist
- Every saved revision has an explicit notification state, even when no email was attempted.
- A lost response cannot create two provider-accepted messages for one version ID.
- The email identifies the correct form, author, time, and revision without exposing sensitive values.
- A later form edit creates a new checksum, revision ID, and independent notification record.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Separate storage and delivery states
- Create one stable notification key
- Trace provider acceptance
- Retry only unresolved delivery
- Alert with redacted evidence
Mistakes to avoid
- Changing production before recording exact versions, UTC time, the affected fixture, current behavior, and a tested rollback point.
- Accepting one successful admin screen while the stored record, API response, queue, email, browser, or downstream system remains unchecked.
- Testing only as an administrator instead of the role, browser, locale, network state, catalog size, and failure path a real user reaches.
- Leaving broad credentials, debug logs, temporary filters, synthetic records, or recovery code active after verification.
Questions teams ask during testing
Should I test this on production?
Use production for read-only evidence first. Reproduce the change on staging with current data, extensions, cache, browser mix, and integration settings. If a production canary is necessary, make it reversible, identifiable, monitored, and unable to charge a customer or expose personal data.
How do I rule out a cache artifact?
Record the origin response, purge only affected paths, and repeat in private and normal sessions. Compare stored data and server logs with the visible page. A cache hit is useful evidence only when you know which version and settings it contains.
What belongs in the evidence packet?
Keep UTC time, exact versions, fixture ID, role, browser, expected result, actual result, relevant response or log lines, change made, rollback point, owner, and final verification. Redact passwords, tokens, personal data, and private URLs.
When is the test complete?
Close it when the main path and important failure branches pass, records reconcile across systems, accessibility and mobile checks are complete, temporary changes are removed, and monitoring covers the next update or business cycle.
What to tell the client or owner
Give the owner a short packet with the affected workflow, exact versions, UTC test time, fixture ID, expected result, actual result, key evidence, change made, rollback point, unresolved risk, owner, and next review date. Remove credentials and personal data before sharing it.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, have HandL WP audit form change alerts.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references