Quick answer
For a large Gravity Forms retention job, measure the records eligible for the policy and their progress across checkpoints. Do not conclude that deletion is stuck because the overall entry count remains high. Recent submissions, excluded records, and entries moved to Trash can all change the apparent result.
Know which operation you are testing
The personal-data settings distinguish retaining entries, automatically trashing them, and permanently deleting them. These outcomes are not interchangeable. Record the selected policy and its age threshold before investigating a job. Never switch from Trash to permanent deletion merely to make the count drop faster.
The 3.1.1 release notes describe background batches for a retention timeout affecting large matching sets. This guide addresses that large-job progress check. If no scheduled work runs at all, first use the separate scheduling diagnostic linked below rather than treating every retention delay as the same defect.
Create a disposable evidence set
Use a dedicated staging form with fictional entries and no active CRM, payment, or customer notification integrations. Include records clearly older than the threshold, clearly newer records, and any supported exception case you intend to preserve. Document the expected outcome for each group before running the policy.
A production database copy is not automatically a disposable test dataset. It can contain personal information and live integration credentials. Minimize the data and isolate outbound actions first. Test the recovery procedure for the staging fixture without restoring over a production site that has received new submissions.
Fix the denominator before counting progress
List the IDs of the fixture records eligible at a defined cutoff. Record the time zone used for the threshold calculation and avoid moving the cutoff between observations. If new submissions arrive during the test, do not add them to the original denominator unless they were deliberately part of the test.
At each checkpoint, separate processed eligible records, remaining eligible records, and records excluded for an explained reason. Also record whether the configured action sends entries to Trash or removes them permanently. A combined total that includes Trash cannot prove that a trashing policy did nothing.
- Eligible at start: the fixed record set under review.
- Processed: eligible records with the intended outcome.
- Remaining: eligible records not yet processed.
- Exceptions: retained records with a verified reason.
Observe work rather than forcing it repeatedly
Have the site maintainer inspect supported background-processing and scheduling evidence for the installed build. Record start times, subsequent checkpoints, and errors. A long-running task that steadily reduces the remaining eligible set is different from one repeatedly failing on the same record.
Do not launch concurrent cleanup attempts or repeatedly force all scheduled events. Those actions can make the evidence ambiguous and affect unrelated jobs. If the worker stalls, preserve the last successful checkpoint and the smallest relevant error before deciding whether a targeted retry is appropriate.
Interpret age thresholds honestly
The settings documentation explains that retention is scheduled rather than guaranteed at an exact age boundary. Allow for the documented scheduling window when deciding whether a record is late. A record just beyond the threshold is not sufficient evidence of a broken cleanup system.
For a large batch, also distinguish waiting to start from time spent processing. Report both where measurable. Do not promise a universal completion time: entry volume, hosting resources, integrations, and background execution conditions differ. The useful question is whether the job makes controlled progress and produces the correct final set.
Do not turn a performance fix into a policy change
If timeouts persist, work on processing and scheduling evidence instead of shortening retention, disabling exceptions, or broadening the deletion selection. Changes to the business retention policy require the appropriate owner's approval and may require professional advice for the organization's obligations.
Check related uploaded files and downstream systems through their documented lifecycle separately. An entry disappearing from the local list is not proof that every copy of associated personal data has been erased. Avoid presenting this technical test as certification of legal compliance.
Define the release gate
A passing test reconciles all initially eligible fixture IDs, preserves recent and intentionally held records, and leaves no unexplained worker failure. Keep the policy screenshot or configuration record, the checkpoint table, and the final count reconciliation together.
Deploy the supported fix through the normal maintenance process. Observe production progress without creating a new destructive experiment. If the result diverges, pause further corrective deletion attempts and retain the evidence for review rather than escalating to a whole-database cleanup.
Illustrative diagnostic worksheet, not results from a customer site.When to bring in help
For Gravity Forms maintenance support, provide the policy, eligible counts, run times, and anonymized error details. Do not send the entry dataset itself. A maintainer should be able to distinguish scheduling failure from stalled batch processing with IDs and counts, without reading customers' submitted information.
Related troubleshooting
Investigate a retention schedule that never runs.
Helpful references
Gravity Forms 3.1.1 release notes. Personal data and retention settings.