Gravity Forms personal data can exist in active entries, spam, partial entries, saved drafts, uploaded files, custom entry meta, add-on tables, logs, notifications, backups, and external services. A successful WordPress export file does not prove each location was searched or erased according to policy.
Use this for privacy request workflows on lead, application, donation, survey, support, ecommerce, and membership forms, especially when add-ons send data to CRMs, email services, storage, or payment systems.
Quick answer
Create one synthetic identity that appears in every supported data location, then run WordPress export and erasure using the configured identification field. Compare expected and actual records location by location, document lawful retention exceptions, and assign external systems to named owners.
What to check first
- Inventory entry, entry meta, spam, trash, partial entry, save-and-continue, file, log, notification, add-on, backup, cache, analytics, CRM, email, and payment locations.
- Define the identification fields and normalization rules used to match email, user ID, phone, submission ID, or another requester identity.
- Seed controlled records in every available state and destination, preserving expected record IDs without using a real customer.
- Run export and erasure separately, then compare the artifact and remaining data against the inventory, retention policy, legal basis, and exception owner.
- Verify uploaded-file links, backup and log handling, downstream requests, audit evidence, requester communication, and repeat-run behavior.
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 |
|---|
| Build the complete data-location inventory | Inventory entry, entry meta, spam, trash, partial entry, save-and-continue, file, log, notification, add-on, backup, cache, analytics, CRM, email, and payment locations. | The export artifact contains every expected registered location. |
| Define identity matching and exceptions | Define the identification fields and normalization rules used to match email, user ID, phone, submission ID, or another requester identity. | Erasure changes only the intended synthetic identity. |
| Seed a synthetic coverage fixture | Seed controlled records in every available state and destination, preserving expected record IDs without using a real customer. | Files, add-on tables, logs, and remote copies have documented outcomes. |
| Compare export and erasure location by location | Run export and erasure separately, then compare the artifact and remaining data against the inventory, retention policy, legal basis, and exception owner. | Retained exceptions have a legal basis, owner, access limit, and expiry. |
Why this usually happens
- Exporters can only search fields and add-ons that register with the WordPress privacy tools.
- Spam and partial-entry states may follow different queries from active entries.
- Files and remote systems can outlive the primary database row.
- A legal or financial retention exception can require restriction rather than immediate erasure.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
test_identity: privacy-test+20260725@example.test
locations_expected: 11
locations_exported: 9
locations_erased: 7
retained_exceptions: [payment_record]
missing_export: [partial_entry, addon_custom_table]
external_actions: [crm_delete_requested, backup_expiry_recorded]
result: needs_fix
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.
- Build the complete data-location inventory
- Define identity matching and exceptions
- Seed a synthetic coverage fixture
- Compare export and erasure location by location
- Assign external actions and repeat the test
Decision rule
Pass when every inventoried location is exported, erased, restricted, or retained under a documented exception, external owners confirm their actions, files and logs follow policy, and a repeated request finds only expected retained data.
What to tell the client or owner
Give the owner the affected versions, 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
- The export artifact contains every expected registered location.
- Erasure changes only the intended synthetic identity.
- Files, add-on tables, logs, and remote copies have documented outcomes.
- Retained exceptions have a legal basis, owner, access limit, and expiry.
Mistakes to avoid
- Do not change several plugins, cache rules, or infrastructure settings before preserving a baseline.
- Do not treat one successful test as proof for retries, alternate clients, or delayed background work.
- Do not paste secrets, personal data, or complete production payloads into tickets or screenshots.
- Do not close the test until the final user-visible state and server-side evidence agree.
Questions teams ask during testing
Does deleting the Gravity Forms entry erase uploaded files?
Not necessarily for every configuration or external copy. Test the file path, media relationship, offload storage, backups, and add-ons explicitly.
Should spam entries be included in a personal data export?
If they contain data tied to the verified requester and no exception applies, the workflow needs a documented way to account for them.
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, audit Gravity Forms privacy request coverage.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Verify the 2.10.5 fix beyond the 60-form boundary
Use the Gravity Forms 2.10.5 60-form privacy regression test to seed synthetic records before, at, and after the old boundary, then reconcile entries, files, add-ons, logs, and external retention.
Helpful references