Gravity Forms survey reports and exports can mix historical entries with current field labels, choices, values, or scoring rules. When an editor renames a choice, reorders options, changes weights, or reuses a field, old answers may display under new language or roll into a score that did not exist when the response was submitted.
Use this for long-running customer, employee, research, training, or assessment surveys where Gravity Forms results feed exports, dashboards, decisions, or compliance records.
Quick answer
Snapshot the form schema and scoring configuration by version and effective date. Select known entries from before and after each change. Compare stored entry values, visible labels, survey results, calculated scores, CSV exports, API output, and BI transformations. Never recompute historical scores with today's weights unless the report says so explicitly. Keep an immutable rule version beside derived metrics.
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 |
|---|
| Label renamed | Same stored value | Historical meaning preserved |
| Choice reordered | Same option IDs | No category swap |
| Weight changed | Before and after entries | Rule version applied |
| Field reused | New question text | Separate reporting cohort |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Version the form schema, choices, and scoring rules with effective dates. | Export field IDs, choice values, labels, order, weights, scoring rules, conditional logic, and effective timestamps for every known form revision. | Known entries before and after each change retain the expected meaning. |
| Join historical data by stable form, field, choice, and rule identifiers. | Choose synthetic and historical entries on both sides of each label, value, order, or weight change. | Entry detail, survey results, CSV, API, and BI rows reconcile by stable IDs. |
| Store the original score and the rule version used at submission time. | Compare entry detail, aggregate survey results, CSV, REST or API output, notifications, and downstream dashboard rows. | Original and restated scores are distinct and carry rule versions. |
| Separate restated analysis from original historical reporting. | Identify reports that join by visible label instead of stable field and choice identifiers. | Future form edits trigger a schema and historical-report impact review. |
What to check first
- Export field IDs, choice values, labels, order, weights, scoring rules, conditional logic, and effective timestamps for every known form revision.
- Choose synthetic and historical entries on both sides of each label, value, order, or weight change.
- Compare entry detail, aggregate survey results, CSV, REST or API output, notifications, and downstream dashboard rows.
- Identify reports that join by visible label instead of stable field and choice identifiers.
- Decide whether historical metrics remain as originally scored or are intentionally restated with a disclosed method.
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.
entry_id,submitted_at,form_version,field_id,choice_value,stored_label,rule_version,score
501,2025-11-02T10:00Z,v3,12,very_good,Very good,score-v2,5
842,2026-08-19T15:00Z,v4,12,very_good,Excellent,score-v3,4
843,2026-08-19T16:00Z,v4,17,very_good,Support quality,none,none
Why this usually happens
- Entry storage and reporting layers can resolve choice labels at different times.
- Human-readable labels are easy to join but unstable over a survey's lifetime.
- A derived score often lacks the rule version used to calculate it.
- Form duplication and field reuse can make two different questions look structurally identical.
Decision rule
Approve a survey report only when every historical response is interpreted with the form and scoring rules in effect at submission, or a restatement is clearly labeled and reproducible.
Production verification checklist
- Known entries before and after each change retain the expected meaning.
- Entry detail, survey results, CSV, API, and BI rows reconcile by stable IDs.
- Original and restated scores are distinct and carry rule versions.
- Future form edits trigger a schema and historical-report impact review.
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.
- Version the form schema, choices, and scoring rules with effective dates.
- Join historical data by stable form, field, choice, and rule identifiers.
- Store the original score and the rule version used at submission time.
- Separate restated analysis from original historical reporting.
- Add a regression fixture before every survey choice or scoring change.
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, audit Gravity Forms survey data.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references