The FormTester 365 Gravity Forms add-on verifies that a test entry was stored through the REST API and can delete it afterward. If someone else built your website, first confirm which tool powers the form you want to test.
Check your WordPress dashboard
If you have access to the site's WordPress administration area, look in the installed plugins list for Gravity Forms. Your website manager can confirm which forms use it. A site may have more than one form tool installed, so match the specific form you want to check.
Look for clues on the page
A developer can inspect the form's markup for Gravity Forms identifiers such as gform. Treat that as a clue rather than a complete inventory of your site's forms. If you are unsure, ask the person who built or maintains the page.
Catch update failures early
A Gravity Forms update can affect a form that worked the day before. In one customer case, a scheduled FormTester 365 test surfaced a failure after an update. The customer reverted to the previous working version while waiting for a fix. Test the published form after any update, and test again before keeping a replacement release.
Check caching when visitors and administrators see different results
A cached page can contain an expired nonce. Gravity Forms documents how cached HTML can cause public Ajax submissions to fail even when a form works for a logged-in administrator. Test the published URL as a visitor, and compare a cached page with a fresh one when investigating.
Decide what to verify
A standard FormTester 365 test checks browser submission success. Its Gravity Forms add-on can verify that a test entry was stored through the REST API and delete the test submission afterward. If the form sends a notification, you can also add the form-specific FormTester 365 address as a BCC recipient where its notification settings allow it. Neither a browser confirmation nor a received BCC copy proves delivery to the primary recipient.
Explore Gravity Forms monitoring or learn how to inspect failed-test evidence.