# Troubleshooting Forms ## Start here: a quick triage order Work through these checks in order. Change one thing at a time, then test again so you know what fixed the problem. - Identify whether the form failed to submit, submitted but showed the wrong confirmation, or submitted but a notification did not arrive. - For payment forms, check Entries before anyone tries again. - Reproduce the issue as precisely as possible. - Disable cache on every page that displays the form. - Check required fields, validation messages, and conditional logic. - Test in a private browser window and, when practical, on another device or browser. - Collect the details below before contacting support. ## First, identify what failed A form problem can happen at different points. Knowing where it stopped saves time and helps prevent duplicate payment attempts. ### The form did not submit The visitor may see validation messages, a spinning button, an error message, or no visible response after selecting Submit. Start by checking the required fields, conditional logic, spam protection, and the browser test steps in this guide. ### The form submitted, but the confirmation was wrong or missing Check Entries first. If an entry exists, the submission may have succeeded even if the visitor did not see the expected confirmation. Review the confirmation settings and any logic that controls which confirmation appears. A confirmation can differ based on answers given in the form. ### The form submitted, but no notification arrived Again, check Entries before treating the submission as failed. An entry confirms that Gravity Forms received the form data, even when a notification needs separate attention. Record which notification was expected, the recipient address, and whether anyone else received it. Do not ask a visitor to resubmit until you have checked whether their original entry exists. ## Payment forms: check Entries before trying again Use extra care with payment forms. A visitor may have completed a payment step even when they did not receive the confirmation they expected. - Check Entries for the visitor’s name, email address, and approximate submission time. - Ask the visitor not to submit again while you check. - Do not assume a missing email or confirmation means no payment was attempted. - Share the form URL and the entry details with support if the result is unclear. ## Reproduce the exact issue “The form is broken” is hard to diagnose. A repeatable description gives support a useful starting point. Try the same path the visitor took, including every answer and every page of a multi-page form. If the form changes based on an answer, test the branch that produced the problem. - Which device was used: phone, tablet, or computer? - Which browser and browser version were used? - Was the person signed in to the site, signed out, or using a private window? - What exact link or URL did they use? - What values did they enter? Do not send payment card details or other sensitive information to support. - Which route did they take through multi-page or conditional steps? - What did they expect to happen? - What actually happened, including the exact error text if one appeared? - Can another person reproduce it? Test in a private browser window after recording the original result. A private-window test reduces the chance that an existing login session, saved browser data, or an extension affects the comparison. If possible, test once in a second browser or on a second device. Different results do not prove the cause, but they give support a clearer comparison. ## Disable cache on every page that displays the form Cache settings are the first site setting to check for a form issue, especially for payment forms. Disable cache on every page where the form appears, not only the page where you first noticed the problem. This includes pages where the same form is placed directly, shown through an embed, or reached during a payment or registration flow. A cached page can make it difficult to tell whether visitors are seeing the current published version. https://youtu.be/Rdo_yXm0H1s ### Disable cache for the page Open the page in the WordPress dashboard. ![Edit Page in Dashboard](https://digitalchurch.com/wp-content/uploads/2026/07/edit-page-in-dashboard-scaled.jpg) In the page editor’s right sidebar, find the **Exclude from Cache** toggle and turn it on. ![Exclude from Cache](https://digitalchurch.com/wp-content/uploads/2026/07/disable-cache-scaled.jpg) Select **Update** to publish the page setting. ![Update the Page](https://digitalchurch.com/wp-content/uploads/2026/07/update-the-page-scaled.jpg) Repeat these steps for each page that displays the form. Then open the public page in a private browser window and confirm that you are testing the current version. ## Check that you are testing the published form A page edit and a form edit are separate changes. Make sure the public page contains the intended form and that the changes you made are visible on the published page. - Open the public page rather than relying only on the editor preview. - Use the exact URL visitors use, including any campaign, giving, or registration link. - Check each page where the form appears. - If the form is embedded in another page or service, confirm that visitors are reaching the current published form. - Test after each change rather than making many edits at once. ## Check required fields and validation Start with the visible fields. A required field, an invalid format, or a value that does not meet the field’s rules can stop a submission. - Complete every visible required field. - Read the validation message exactly as shown. - Check email addresses, dates, phone numbers, and other formatted fields with a simple test value. - Confirm that a field is not required when it is hidden by conditional logic. - Test the same answers that caused the original report. If a field becomes visible only after a certain answer, test both paths. A working path and a failing path can point to a condition that needs review. ## Inspect conditional logic Conditional logic can affect fields, sections, pages, confirmations, notifications, and payment-related choices. Review the logic wherever the form changes behavior. - Check whether the rule should use **all** conditions or **any** condition. - Look for required fields that are hidden under one answer path. - Check rules tied to choices that were renamed, removed, or changed. - Test the page and section behavior for each affected path. - Follow every step in a multi-page form to confirm that the visitor reaches the expected next page. - Review confirmation and notification logic when the entry exists but the response is not what you expected. Make one logic change, test the affected route, and then move to the next change. This keeps the result clear. ## Check spam protection and Turnstile Spam protection can affect form submission. If the issue appears only for some visitors, record what they saw and whether the same result happens in a private browser window. Check whether Turnstile or another spam-protection step appears as expected on the public page. Do not disable protections broadly just to test a single report; send the details to support if the behavior remains unclear. ## Retest carefully Use a controlled test after each change. For a simple contact form, submit a test entry and confirm the result in Entries, the confirmation, and the expected notification. For payment forms, avoid repeated live test submissions. Check Entries before retrying, keep a record of the test time and email address used, and stop if the payment result is unclear. ## What to send support Send a short, complete report. Screenshots or a screen recording help when they show the issue without exposing sensitive information. - The form name and the exact page URL. - Whether the problem is submission, confirmation, notification, or payment-related. - The date, time, and timezone of the test or visitor report. - Device, browser, and login state. - The exact steps and non-sensitive values used to reproduce it. - The route through multi-page or conditional steps. - The exact error message or a screenshot of it. - Whether an entry exists. - Whether the page’s **Exclude from Cache** toggle is enabled on every page displaying the form. - Whether the issue also happens in a private browser window, another browser, or on another device. - Any recent changes to the page, form, choices, conditional logic, or payment setup. Never include payment card details, passwords, or other sensitive visitor information in a support request.