Do not use GravityView's Remove Data option as routine troubleshooting. It is a destructive cleanup operation. Before confirming it, establish exactly which notes, approval states, settings, and permissions your workflow depends on, and prove that your backup can restore them.
What the new option removes
The GravityView 3.10.0 changelog describes removal of entry approval statuses, GravityView-added entry notes, and GravityView settings, plus resetting user-role permissions. Views themselves are retained. Keeping View definitions is not the same as preserving the state that controls how those Views operate.
The option is exposed through GravityView settings, Manage Your Kit, and the plugin deactivation dialog. Read the exact dialog in your installed version. Deactivation and choosing an additional data-removal action are not interchangeable decisions. Do not assume clicking through a new prompt has the same effect as an older deactivation workflow.
Decide whether cleanup is actually needed
Write the intended outcome first. Are you retiring the application, starting a clean test installation, or trying to fix a display error? For a display error, begin with the relevant diagnostic rather than erasing configuration. For an access problem, use the protected-entry boundary checks.
Identify the business owner who can approve losing the affected state. A site administrator may have technical access without knowing why an approval flag or moderator note must be preserved. Do not make cleanup an automatic step in a support script, deployment hook, or plugin update checklist.
Removal scope versus recovery evidence: retained Views do not prove that approval states, notes, settings or role permissions survived. Explanatory diagram.
Build a recovery inventory
Use a staging copy and list the Views, linked forms, approval workflow, role capabilities, and any dependent extensions. Capture non-sensitive configuration evidence. For notes and approval states, record counts and a few synthetic examples that demonstrate the state you need to recover.
| Item |
Evidence to preserve |
Restoration check |
| Entry approvals |
Known approved and unapproved test IDs |
Each returns to the intended state |
| GravityView notes |
Synthetic note attached to a test entry |
Text and association return |
| Settings |
Relevant configuration record |
Expected behavior returns |
| Role permissions |
Allowed and denied test roles |
Both boundaries remain correct |
| View definitions |
View IDs and form relationships |
Existing layouts still resolve |
A form-entry CSV is not a complete backup of this application state. It may be useful for analysis, but it does not prove restoration of plugin settings, permissions, or notes. Use your host's supported database-and-files backup process and retain the compatible plugin versions needed for recovery.
Prove restoration before deletion
Restore the backup into a separate, access-restricted staging environment. Isolate outbound mail, payment connections, and other production integrations so a recovery drill cannot contact real customers or duplicate business actions. Keep the restored copy away from search indexing and unauthorized visitors.
Check the synthetic approved and unapproved entries, the note association, the intended member view, and a denied visitor. A backup file existing in storage is not sufficient evidence. The useful question is whether the restored installation reconstructs the workflow and its access boundaries.
If the site continues accepting submissions, record the recovery point and the new records created after it. Restoring an older database can overwrite newer work. Agree on a maintenance window and a reconciliation plan before any production cleanup; do not discover that conflict after a delete action.
Check the application after an authorized removal
Only an authorized owner should confirm the destructive operation after reviewing its scope. This guide does not perform or authorize that action on your site. Afterward, inspect retained Views, dependent components, settings, and role behavior against the agreed cleanup outcome.
Do not treat missing approval metadata as equivalent to an explicitly approved record. Verify what your installed configuration now exposes to each visitor role. Pause access to sensitive workflows if the resulting behavior is uncertain, and restore through the tested recovery procedure when necessary.
For a planned retirement, retain or dispose of backups under the organization's actual retention policy, not an arbitrary period from a troubleshooting article. HandL WP can help plan a recoverable cleanup with a documented scope and restoration test. The decision to permanently remove business records remains with the responsible owner.
Sources reviewed November 1, 2026. Examples and diagrams are diagnostic aids, not customer test results.