A scheduled Gravity Forms survey export can finish successfully while using the wrong date boundary, including spam or partial entries, writing to a public directory, emailing an expired link, duplicating rows after retry, or retaining personal data indefinitely. The useful test follows the export artifact from selection through deletion.
Use this for survey exports delivered to clients, analysts, S3, SFTP, email, BI systems, or compliance archives on a recurring schedule.
Quick answer
Define the exact form, fields, status, filters, time zone, window, destination, recipients, encryption, retention, and deletion owner. Use fixture entries just before, at, and after the window boundary, including spam, trash, partial, deleted, Unicode, formula-like, and uploaded-file cases. Run success, retry, timeout, partial delivery, and deletion. Reconcile entry IDs and file hashes at every stage.
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 |
|---|
| Window boundary | Before, exact, and after time | Expected IDs only |
| Retry | Timeout after upload | One final artifact |
| Access | Anonymous and named role | Least privilege |
| Retention | Expiry plus legal hold | Documented deletion result |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Write the selection, time-zone, access, encryption, and retention contract before scheduling. | Record the scheduler, form ID, field IDs, entry status filters, site time zone, UTC conversion, window inclusivity, and expected entry IDs. | The artifact contains exactly the expected entry IDs and field values. |
| Use one export run ID and deterministic object key across retries. | Create boundary fixtures plus spam, trash, partial, deleted, Unicode, multiline, formula-like, and upload rows. | Retries produce one logical export and one approved destination object. |
| Store artifacts in private destinations with short-lived, named access. | Inspect local, temporary, S3, SFTP, email, and downstream copies for encryption, public access, MIME type, filename, and checksum. | Anonymous and unapproved users cannot fetch the file or expired link. |
| Escape spreadsheet-risk values without altering the original survey meaning. | Retry after timeout and partial delivery with one export run ID so files and rows cannot duplicate silently. | Temporary, transfer, destination, email, and downstream copies follow retention policy. |
What to check first
- Record the scheduler, form ID, field IDs, entry status filters, site time zone, UTC conversion, window inclusivity, and expected entry IDs.
- Create boundary fixtures plus spam, trash, partial, deleted, Unicode, multiline, formula-like, and upload rows.
- Inspect local, temporary, S3, SFTP, email, and downstream copies for encryption, public access, MIME type, filename, and checksum.
- Retry after timeout and partial delivery with one export run ID so files and rows cannot duplicate silently.
- Execute retention and legal-hold branches, then prove every temporary and destination copy is deleted or intentionally retained.
Field notes
- Use synthetic IDs and examples that can be traced from the first request to the final record.
- Keep a before and after result for every changed setting or deployed version.
- Review the evidence again after caches, queues, and scheduled work have had time to settle.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
run_id,window_start,window_end,timezone,expected_ids,file_sha256,destination,expires,result
SUR-821,2026-08-20T00:00,2026-08-21T00:00,America/Chicago,701|702,a91f...,s3-private,2026-09-20,pass
SUR-822,2026-08-21T00:00,2026-08-22T00:00,America/Chicago,703,b18c...,email-link,2026-08-28,retry
Why this usually happens
- Site time, scheduler time, destination time, and analyst time can differ.
- A transfer can succeed after the scheduler times out and starts a retry.
- Temporary files are often outside the destination retention policy.
- Spreadsheet software can interpret survey text as formulas when exports are opened.
Decision rule
Approve the scheduled export only when selection boundaries are reproducible, retries are idempotent, every copy is private, and retention plus deletion can be proven by run ID.
Production verification checklist
- The artifact contains exactly the expected entry IDs and field values.
- Retries produce one logical export and one approved destination object.
- Anonymous and unapproved users cannot fetch the file or expired link.
- Temporary, transfer, destination, email, and downstream copies follow retention policy.
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.
- Write the selection, time-zone, access, encryption, and retention contract before scheduling.
- Use one export run ID and deterministic object key across retries.
- Store artifacts in private destinations with short-lived, named access.
- Escape spreadsheet-risk values without altering the original survey meaning.
- Reconcile expected entry IDs, hashes, copies, recipients, expiry, and deletion.
Mistakes to avoid
- Changing production before recording exact versions, UTC timestamps, stable fixture IDs, settings, and a reproducible baseline.
- Treating one successful screen as proof that APIs, caches, jobs, roles, reports, and downstream records agree.
- Testing only an administrator session instead of the devices, roles, networks, data states, and failure branches customers use.
- Closing the task without a named owner, rollback point, observation window, and contextual incoming link from an established guide.
Questions teams ask during testing
Can this be tested on production?
Use production for read-only confirmation and one narrow synthetic fixture that cannot charge a card, email a real customer, expose personal data, or alter inventory. Run upgrades, schema changes, cache changes, and destructive repairs on staging first.
What evidence should the report keep?
Keep exact versions, UTC timestamps, stable synthetic IDs, expected and actual results, the decision owner, rollback point, and final verification. Redact credentials, tokens, customer data, addresses, and private infrastructure details.
When is the task complete?
Complete it when the primary user path passes, downstream records reconcile, failure branches are understood, monitoring is active, and an established owner page links to the new guide in context.
What to tell the client or owner
Give the site owner the affected versions, exact synthetic fixture, UTC timeline, before and after evidence, cause class, decision, rollback point, unresolved risks, and next review date. State which measurements prove success and which observation window remains open.
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, secure a Gravity Forms export workflow.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references