WPForms says conditional logic works with Prefill by URL and is applied after fields are dynamically filled. Real pages add caches, optimizers, multi-step forms, AJAX, dynamic choices, hidden fields, consent, and custom scripts that can change that order. A field may appear correctly while the entry stores a different value, or a hidden attribution field may persist after the visible branch changes. The test joins URL, render state, logic branch, validation, entry, notification, webhook, and CRM evidence.
Use this when a URL-prefilled WPForms value should reveal or hide fields, route a notification, set a hidden value, or control a CRM workflow.
Quick answer
Create a fixture for every allowed prefilled value plus missing, invalid, encoded, repeated, and stale values. Record the final URL and rendered field before interaction, then confirm the expected conditional branch. Submit invalid and valid attempts through AJAX and non-AJAX paths. Compare the entry, hidden fields, notification route, webhook, CRM, and analytics event. Clear page cache and repeat because stale markup or delayed scripts can make the visible branch disagree with the stored record.
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 |
|---|
| Valid route | Prefilled stored choice | Expected branch visible |
| Unknown value | No allowed choice | Safe default |
| AJAX retry | Invalid then valid | Logic recalculates |
| Hidden value | Entry and CRM | Matches approved branch |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
|---|
| Map field and rule contracts | Inventory the prefilled source field, documented URL key, choice values, show-values setting, conditional rules, hidden fields, notifications, confirmations, webhooks, and CRM mappings. | Every allowed URL value selects the expected conditional branch. |
| Build valid and invalid fixtures | Create fixtures for every valid route plus missing, invalid, repeated, encoded, translated, cached, and tampered values. | Unknown, stale, or tampered values fall back safely without leaking hidden state. |
| Capture render and logic order | Capture the final URL, initial rendered value, logic evaluation, visible fields, required markers, focus order, browser console, and network requests before submission. | AJAX retries and cached pages store the same result as a clean non-AJAX submission. |
| Compare AJAX and stored evidence | Submit invalid then valid attempts in AJAX and non-AJAX modes and compare entry, hidden values, notification, confirmation, webhook, CRM, and analytics. | Entry, notification, webhook, CRM, and analytics evidence join to one fixture ID. |
What to check first
- Inventory the prefilled source field, documented URL key, choice values, show-values setting, conditional rules, hidden fields, notifications, confirmations, webhooks, and CRM mappings.
- Create fixtures for every valid route plus missing, invalid, repeated, encoded, translated, cached, and tampered values.
- Capture the final URL, initial rendered value, logic evaluation, visible fields, required markers, focus order, browser console, and network requests before submission.
- Submit invalid then valid attempts in AJAX and non-AJAX modes and compare entry, hidden values, notification, confirmation, webhook, CRM, and analytics.
- Retest after form duplication, field-ID change, cache purge, optimizer change, translation update, and consent transition.
Field notes
- Write the expected result before changing anything and keep one repeatable canary fixture for the full test window.
- Record exact versions and UTC timestamps because caches, retries, scheduled actions, and deployments can change the evidence between checks.
- Test the public browser path and the stored server-side result, not only an admin preview or isolated API response.
- Close the task only after the visible workflow, logs, stored record, and relevant downstream system agree.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
fixture=wpforms-prefill-sales
url_key=wpf20_4
url_value=sales
visible_branch=sales-fields
hidden_route=sales-us
entry_route=sales-us
crm_route=sales-us
result=pass
Why this usually happens
- The URL supplies a visible label while conditional logic compares a stored choice value.
- Cached markup reflects an old rule or form ID and scripts evaluate a different configuration.
- An AJAX retry retains hidden state from the first failed attempt.
- The visible branch is treated as proof without checking the entry or downstream route.
Decision rule
Approve the rule only when the prefilled value, visible branch, validation, hidden fields, entry, notification, webhook, and CRM all resolve to the same approved route.
Production verification checklist
- Every allowed URL value selects the expected conditional branch.
- Unknown, stale, or tampered values fall back safely without leaking hidden state.
- AJAX retries and cached pages store the same result as a clean non-AJAX submission.
- Entry, notification, webhook, CRM, and analytics evidence join to one fixture ID.
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.
- Map field and rule contracts
- Build valid and invalid fixtures
- Capture render and logic order
- Compare AJAX and stored evidence
- Retest cache and lifecycle changes
Mistakes to avoid
- Changing production configuration before recording the exact version, failing request, timestamp, and rollback point.
- Treating a clean dashboard or one successful request as proof while the public page, background job, log, stored record, and downstream system remain unchecked.
- Testing a different role, device, locale, order state, form, cache state, or integration path from the one that users actually reach.
- Leaving debug logging, temporary exclusions, duplicate hooks, helper code, test endpoints, or broad permissions active after the verification window.
Questions teams ask during testing
Can I make this change directly in production?
Start with read-only evidence and use staging for code, update, security, checkout, form, or queue changes. If production is required, use one named canary, a short monitored window, and a tested rollback.
How do I avoid a false positive?
Repeat the same fixture with the same versions, role, URL, device, locale, cache state, and downstream integration. Compare stored evidence rather than relying on a visual impression.
What evidence should I retain?
Keep UTC time, exact versions, URL or record ID, expected and actual result, relevant log lines, change made, rollback point, owner, and final verification. Redact credentials and personal data.
When should I escalate?
Escalate when the site is unavailable, security scope is unclear, checkout or lead capture is affected, several systems disagree, or the next action could destroy evidence.
What to tell the client or owner
Give the owner a concise evidence packet with the affected workflow, exact versions, UTC test time, fixture ID, expected result, actual result, key logs, change made, rollback point, final result, owner, and next review date. Remove credentials and personal data before sharing it.
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, have HandL WP test the WPForms conditional workflow.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references