Quick answer
If a Gravity Form stops displaying after a rule references the last-name input, check whether that input is actually present. Gravity Forms 3.1.1 fixes a JavaScript error involving this missing dependency. Update through the supported channel and correct any rule that no longer represents the form's intended structure.
Capture the failure before changing the form
Open the affected page as a logged-out visitor and note whether the form is entirely absent, partly rendered, or present but unresponsive. Use the browser Console to capture the first relevant error after a fresh load. Later errors may be consequences of the first failure.
Also record the form ID and page URL. A site can embed different forms on desktop landing pages, translated pages, and popups. Comparing the wrong form in the editor with the public failure leads to unnecessary changes and makes a reproducible issue look intermittent.
Inspect the Name field structure
In the form editor, locate the Name field used by the conditional rule. Review which name inputs are configured and which are actually rendered. Do not assume a field's visible label tells you which internal inputs exist.
Compare the rule's target with the rendered page using the browser inspector. You are looking for a reference to an input that was removed, disabled, or replaced during a redesign. Keep the distinction between an absent input and an input hidden by legitimate conditional logic; they are not the same condition.
Preserve the original routing intent
Before changing the rule, ask what business decision it was supposed to make. A last-name condition used as a proxy for a customer type may deserve a dedicated choice field instead. Do not replace it with an always-true rule merely to make the form appear.
On staging, clone or export the form configuration before editing. Change one dependency at a time and record the expected branches. If the last-name input is genuinely required by the workflow, restore it intentionally. If it is no longer collected, revise the rule to use a valid input that expresses the intended decision.
- Name input present and populated.
- Name input present but empty.
- The rule's matching condition is true.
- The rule's matching condition is false.
Apply the supported fix and verify asset freshness
Check the installed Gravity Forms version against the official release notes. Use the current supported update available to your account, preserving a backup and staging test. Avoid copying a small section of vendor JavaScript from an online answer into production.
After updating, follow the vendor's cache and script-optimization guidance for form pages. Verify the public page is loading current markup and assets. A successful administrator preview can bypass cache behavior that still affects visitors, so it is not a complete acceptance test.
Test validation after the display returns
A rendered form is only the first checkpoint. Submit the empty fixture and verify the expected required-field errors. Then complete each relevant logic branch and submit one valid test entry. Inspect the saved values and any dependent notifications or feeds.
Contain test mail and integrations on staging. If the form initiates payment, registration, or workflow actions, use their supported sandbox arrangements. A visual fix should not be tested by repeatedly creating live customer records.
Check other embeddings without broad refactoring
Test the same form in any popup, conversational layout, or AJAX-rendered surface that the site actually uses. Only include real supported placements, not a speculative matrix of every possible plugin combination. The goal is to verify the user journeys you maintain.
If one placement still fails, compare its initialization and asset handling with the working page. Keep that as a separate finding rather than undoing the corrected rule. A form-definition issue and an embedding issue can coexist.
Hand over the smallest reproducible case
A useful escalation includes the exact form version, the relevant Name field configuration, the conditional rule, the public error, and the expected branch behavior. Include the test that passed and the one that failed. This lets a developer focus on the dependency instead of rebuilding the whole form.
Once the fix is live, review the next legitimate entries for missing values or misrouted follow-up. Preserve the prior configuration long enough for a controlled rollback, but do not leave duplicate public forms competing for the same submissions.
Illustrative diagnostic worksheet. Use your own test results.When to bring in help
Use Gravity Forms debugging support if the field dependency looks correct but the form still fails. Bring a sanitized form export, plugin versions, and the first console error. Remove notification addresses and integration secrets from the reproduction.
Related troubleshooting
Audit hidden required fields and validation.
Helpful references
Gravity Forms 3.1.1 release notes.