Gravity Forms Reload Form - WordPress Plugin

Gravity Forms Reload Form Guide: Resubmitting AJAX Forms Without Reloading the Page

Gravity Forms Reload Form is not meant to replace your form builder. It solves one very specific moment in a form's lifecycle: the user submits their data, sees a confirmation, and the site needs to show that same form again without a full page reload. In a standard Gravity Forms setup, a successful submission replaces the form with a confirmation message. That behavior works fine for a contact form, but it becomes awkward when the same form needs to be filled out repeatedly.

This guide walks through a practical Gravity Forms Reload Form setup: where to enable AJAX, where to place the merge tag, how to choose between a link and an automatic timer, when to preserve entered values, how to handle dynamically populated data, and what to check if the form does not return after submission. It is written for site owners, editors, WordPress administrators, and developers who need a safe way to enable repeat submissions without relying on a homemade page reload.

The plugin is especially useful for internal operator forms, check-in desks, short lead forms, modal windows, repeat service requests, event intake forms, and any workflow where a visitor or staff member needs to start the next entry quickly. At the same time, it should not be treated as a universal "reset everything" tool. Success depends on AJAX form embedding, a correct confirmation message, JavaScript working properly on the page, cache behavior, and any other Gravity Forms add-ons involved in filling or repopulating fields.

This guide does not cover purchasing, license bypassing, or connecting third-party secrets. We are looking at a working setup for a product you already have, a safe way to verify the outcome, and the cases where another approach is the better choice.

What Problems a Post-Submission Form Reload Actually Solves

The strength of Gravity Forms Reload Form is that it does not try to redesign the entire Gravity Forms architecture. The plugin works alongside an existing form and adds a way to bring that form back after a successful AJAX submission. In the simplest setup, the user sees a "Thank you" message and a link such as "Submit another entry." Once they click it, the form reappears in the same place on the page. In the automatic mode, the form comes back on its own after a set delay.

This kind of behavior is useful in projects where one successful submission does not end the workflow. If a visitor submits a single support request, a confirmation message without a fresh form is usually enough. But if a front-desk staff member is entering visitors one after another, closing the tab, refreshing the page, or finding the form again after every record quickly gets in the way. Gravity Forms Reload Form is specifically designed for repetitive data entry, where speed, a clean form state, and no unnecessary page reload matter.

Repeat submissions on the same screen

A typical example is an internal form used by an operator logging requests from phone calls. They enter the name, contact details, and request topic, submit the record, see a brief confirmation, and move straight to the next call. Without reloading the form after submission, the operator has to refresh the page or navigate back, which creates small delays and increases the risk of accidentally submitting old data again.

On the public side of a site, the same pattern shows up at events, service salons, clinics, showrooms, and education projects. The device may be shared, and the form needs to be ready for the next person right away. In that case, it becomes especially important not to keep the previous submitter's personal data unless there is a specific reason to do so.

Forms inside modal windows

Another category is forms inside a popup or modal. The user opens the window, submits the request, sees the confirmation message, and closes the window. The next time they open it, they expect to see a clean form, not the old success message. Gravity Wiz separately documents setups for Popup Maker, Fancybox, and Magnific Popup where the form reloads when the modal is closed. This is not the default use case for every form, but for marketing popups and quick lead forms it is often the deciding factor.

Dynamically populated fields

If the form uses Populate Anything or Easy Passthrough, reloading the form is more than a visual reset. On reload, fields can receive fresh values from the data source or from the latest entry. That matters when the available options changed after the first submission, a new entry appeared, the user context was updated, or the next submission needs to inherit part of the previous one.

Where a form reload delivers real value

Use case	What changes for the user	What to watch for
Internal registration	After submission, the operator immediately gets a fresh form.	You usually want a clean reload without preserving personal data.
Shared tablet or front desk	The next person does not see the previous submission.	You need a short delay so the confirmation can still be read.
Lead form in a popup	When the popup is opened again, it shows the form instead of the old confirmation message.	You need to tie the reload to the close event of that specific modal window.
Form with dynamic values	After reload, the fields pull in up-to-date data.	You need to verify Populate Anything, Easy Passthrough, and cache behavior.

If your use case is just a one-time contact form submission, this plugin may be more than you need. But once the form becomes a working tool for repeat entries, it removes a small but constant operational pain point.

What to Understand Before Installing It

Before installation, it helps to separate three different Gravity Forms mechanisms. First, there is the form submission itself. Second, there is the confirmation, meaning the response the user sees after a successful submission. Third, there is the form reload added by Gravity Forms Reload Form. The plugin starts working after a successful submission, and it does not override required field validation, conditional logic, notifications, feeds, or entry creation.

The key requirement is that the form must be embedded with AJAX enabled. Gravity Wiz explicitly states in its documentation that GP Reload Form works with AJAX forms. That makes sense: if the form submits through a standard postback, the whole page is already reloading, so the plugin has nothing to "redraw" inside the current container. That is why the first check is always the same: the form must submit via AJAX on the page where you expect to show the form again without refreshing the page.

Check how the form is embedded

In the WordPress block editor, the form is usually added with the Gravity Forms block. That block has an AJAX setting that enables submission without a full page reload. If the form is inserted via shortcode, make sure the shortcode includes the AJAX parameter. If the form is rendered through a PHP function in the theme, the developer needs to pass the AJAX parameter in the function call and make sure the Gravity Forms scripts are loaded correctly.

Do not mix up two different concepts: AJAX submission and AJAX loading through Cache Buster. The first controls whether the form submits without reloading the page. The second can load a fresh form while bypassing page cache. Both can be useful, but Reload Form depends specifically on the form's AJAX behavior after submission.

Check the confirmation message

Gravity Forms can show a confirmation as an on-page message, send the user to a page, or redirect to a URL. Gravity Forms Reload Form uses a merge tag inside the confirmation message. That means the basic reload link requires the text-based confirmation option, where you can insert {reload_form:Your Link Text} or a similar string. If the form is configured only for a redirect, the reload link will not appear in place of the form because the user leaves the current page.

For most use cases, choose a confirmation message with a short success text and a link for another submission. If the business logic requires a redirect to a separate thank-you page, Gravity Forms Reload Form may not be the right tool for that particular form.

Check permissions and how Gravity Wiz products are installed

Gravity Wiz has moved product management into Spellbook. In the current documentation, Spellbook is described as the platform plugin for licensing, installation, updates, and product discovery across Gravity Wiz products. For an administrator, that means a Perk is usually installed through the Spellbook section in WordPress rather than the older model where one shared Gravity Perks plugin handled everything. There is no need to put license details into the article or share them with anyone. The only thing that matters here is that a user with administrator permissions must be able to install and activate plugins, and Reload Form itself must be activated as a separate product.

Quick preflight check: the form is embedded with AJAX, the confirmation is shown as an on-page message, Gravity Forms is working without JavaScript errors, the administrator has access to Spellbook or manual ZIP installation, and the form page is not being broken by caching or script optimization.

When the product may not be the right fit

Gravity Forms Reload Form is not needed if you only want to clear HTML fields on the page without creating a new entry. It does not replace anti-spam protection, fix broken notifications, solve email delivery problems, or turn a form into a multi-step flow. If the goal is to let the user return to a draft later, look at Save and Continue or entry editing solutions. If the goal is to pass data between different forms, Reload Form may take part in the setup, but the main mechanism will come from Easy Passthrough or dynamic population.

Installation Through Spellbook and the Initial Verification

The exact installation interface depends on how Gravity Wiz products are already managed on your site. In the latest documentation, Gravity Wiz points to Spellbook as the central place for installation, licensing, and updates. So the general path looks like this: install Spellbook, activate it, open the Gravity Wiz products section, find GF Reload Form, and activate the required Perk. If your site has been using Gravity Perks for a long time, check the current Gravity Wiz migration documentation, because Spellbook may replace the old platform plugin without losing the settings of individual Perks.

After activation, do not start by editing every form at once. It is better to choose one test form or a copy of a live form. That makes it much easier to separate a Reload Form configuration issue from problems caused by the theme, cache, fields, or third-party extensions.

Step-by-step installation at a high level

1. Log in to WordPress as a user who can install and activate plugins.
2. Make sure Gravity Forms is already installed, activated, and the form submits without errors.
3. Install and activate Spellbook using the Gravity Wiz documentation, or use the manual ZIP workflow approved for your site.
4. In the Spellbook section, find GF Reload Form or Gravity Forms Reload Form and activate the product.
5. Open a test form, go to its settings, and check whether the Reload Form settings area appears or whether the merge tag is available in confirmations.
6. Place the form on a test page with AJAX enabled and make sure a standard submission creates an entry.

At this stage, the goal is simple: not to perfect the confirmation text yet, but to confirm that the Perk is connected and visible in the context of a specific form. If the Reload Form tabs or fields do not appear, first check whether the product is active, whether the user has the right permissions, and whether it is compatible with the installed Gravity Forms version. Do not start debugging JavaScript on the page until you know the Perk itself is active.

How to verify that AJAX is actually enabled

The simplest user-facing test is to submit the form and see whether the entire page refreshes. If the browser visibly redraws the whole page, the address bar flashes, and you see a standard load, AJAX may be off. If the confirmation message appears in place of the form without a full page reload, the core requirement is met. In the admin area, check the AJAX setting in the Gravity Forms block, shortcode, or PHP call.

For a developer, it is also useful to inspect the browser console. The gform_confirmation_loaded event in Gravity Forms fires on AJAX-enabled forms when the confirmation message is displayed after submission. If the form sits inside a page with other scripts around it, this event often helps confirm that Gravity Forms reached the confirmation stage and the issue is already inside the extra reload logic, the modal, or the theme.

What counts as a successful initial check

The first check is successful if the form creates an entry, shows a confirmation message on the same page, throws no JavaScript errors, and makes Reload Form available in the settings or shows the merge tag in the merge tag insertion list. Once that is confirmed, you can move on to the actual behavior configuration.

Configuring the {reload_form} Link in the Confirmation Message

The core behavior of Gravity Forms Reload Form is built around the merge tag {reload_form:Your Link Text}. You add it to the form's confirmation message. When the user submits the form, the plugin replaces that merge tag with a link. After the user clicks the link, the form reloads inside its AJAX container and the user can submit a new entry.

Where to find the setting you need

Open the target form in Gravity Forms, go to the form settings, and choose Confirmations. In most real-world cases, editing the Default Confirmation is enough, but if the form uses conditional confirmations, you need to decide which of them should include the reload link. Do not insert the merge tag into every confirmation automatically. Sometimes one branch should end with a "please wait for our reply" message, while another should offer the next submission.

In the confirmation message field, add a short success message and the merge tag. For example:

Thank you, your submission has been saved.
{reload_form:Submit another entry}

The text after the colon becomes the link text. It should read like a normal CTA for that specific form. For an internal operator form, "Add the next record" works well. For a public event form, "Fill out the form again" is clearer. For a lead form inside a modal, "Submit a new request" makes sense.

How to choose the link text

Poor reload link text makes the user guess what will happen. Words like "Reload," "Reset," or "Again" may be clear to a developer, but not necessarily to a visitor. In any interface, it is better to describe the action directly: "Fill It Out Again," "Submit Another Request," or "Add the Next Participant." If the form is used by staff, the text can be shorter, but it should still match the task.

The link should come after the confirmation message, not before it. The user should first see that the submission was successful and only then get a path to the next submission. For forms that handle personal data, use neutral wording without details from the previous request so the next person on a shared device does not see more information than they should.

How to test the link

1. Open the page with the form in an incognito window or a separate browser.
2. Fill in the minimum required fields and submit the form.
3. Make sure the confirmation message appears with your link.
4. Click the link and wait for the form to return.
5. Check whether the first entry was created in the Gravity Forms admin area.
6. Submit a second entry and make sure it did not overwrite the first one.

The main success criterion: the user can make two different submissions in a row, and the entries list shows two separate records with the expected values.

When to use multiple confirmations

If the form has different outcomes, the reload link does not need to appear in every confirmation. For example, a pre-booking form may show the reload link for a standard request but not for a request where the user selected a complex case and needs to wait for a manual response. Since Gravity Forms confirmations can use conditional logic, Reload Form should follow the meaning of the form rather than applying the same behavior to every branch.

Keep "repeat the form" separate from "continue another process." If the user should move to the next page, open an account area, or pay for an order after submitting, the reload link may get in the way. In those cases, it is better to keep a redirect or page confirmation and use Reload Form only for repeat-entry forms.

Automatic Reload: When a Timer Works Better Than a Manual Link

Gravity Forms Reload Form can reload the form automatically after a set number of seconds. This is useful when the user should not have to make a separate choice. For example, at a registration desk, it may be enough for someone to see "Thank you, your information has been received," after which the form returns on its own for the next visitor. An internal operator may not need a link either if every record ends the same way.

Automatic reload is configured in the form settings under the Reload Form section. You enable the automatic reload option and then set a delay in seconds. The right value depends on the length of the confirmation message and how the user behaves. If the delay is too short, the person may not have enough time to read the confirmation. If it is too long, the automatic mode becomes almost pointless.

How to choose the delay

A short confirmation needs only a brief pause. A confirmation that includes instructions, a request number, a note about the next step, or a warning needs more time. Do not use automatic reload for confirmations where the user needs to copy a number, download a file, follow a link, or carefully read a legal notice. In those cases, a manual link is the safer choice.

A good rule of thumb is this: automatic reload works well if the confirmation only answers "Did the submission go through?" and does not contain an important action. If the confirmation answers "What do I need to do next?", keep a manual link or increase the delay.

Automatic reload and accessibility

When a message disappears automatically, it can be inconvenient for users who need more time to read. If the form is public and the audience is unknown, do not use an instant reload without a clear reason. For internal screens, you can train operators and use a shorter delay. For a public form, it is usually better to let the user stay in control with a link or at least a noticeably longer delay.

Do not enable instant reload on forms where the confirmation contains important instructions. The user needs enough time to understand the submission outcome before the form appears again.

How to test the timer

Testing automatic reload is similar to testing the link, but you also need to observe the timing. Submit the form, measure the delay, make sure the confirmation message does not disappear too quickly, wait for the form to return, and submit another entry. Then check entries, notifications, and any feeds. If the form integrates with a CRM, email marketing platform, or internal webhooks, it is important to confirm that the repeat submission is not treated as an accidental duplicate and passes through all rules correctly.

If the form feeds into analytics, remember that repeat AJAX submissions and the form returning are not the same as standard page views. Success tracking should be based on the submission event or the confirmation, not a page view. That applies beyond Reload Form, but the mistake becomes more visible here because a user can submit several entries in one session without navigating anywhere.

Preserve Values and Fresh Dynamic Data

By default, GF Reload Form clears field values when the form reloads. That is the safest option for shared devices and public forms. But there are cases where some or all values should remain: an internal operator is entering similar records repeatedly, an administrator is creating a series of requests for one organization, or a user is submitting several items with the same contact details. That is what the Preserve Values from previous submission setting is for.

When value preservation is enabled, the form comes back after reload with values from the previous submission. That does not mean a new entry already exists or that the data keeps "living" on its own. The user still submits a new entry, but they are no longer starting from a blank form. Preserve Values should only be enabled where reusing data genuinely reduces mistakes and does not expose someone else's information.

When preserving values is useful

Preserving values makes sense when the same operator is creating a series of similar entries. For example, a staff member is registering participants from the same company: the company name and primary contact repeat, while the participant name changes. In that situation, enabling Preserve Values saves time and reduces repeat typing. But if the form is sitting on a tablet for visitors, you should not preserve the previous person's email, phone number, or address unless you have separate logic to clear them.

If the form includes sensitive data, use a fresh reload without preserving values. If you only need to keep safe fields, use a confirmed Gravity Wiz snippet from their library to clear specific fields while Preserve Values is enabled, or implement a small server-side filter based on a documented extension point. Do not delete data directly from the database or edit plugin files.

Dynamic population through Populate Anything

Gravity Wiz notes that fields populated through Populate Anything are refreshed on reload. That is an important distinction from simply "clearing the form." If a choice list depends on Gravity Forms records, users, WordPress posts, terms, or database values, reloading the form should reflect the current state. For example, after the first submission, the number of available slots may change, and the next user should see the updated options.

Cache is especially important here. If the page is cached, a dynamic list may still look stale even if Reload Form itself is working. In that case, Cache Buster or excluding the specific page or form from cache may be worth considering, but it should be done narrowly. Disabling cache across the entire site is rarely a good solution.

Easy Passthrough and reusing entry data

Easy Passthrough passes data from one Gravity Forms entry into another form. Combined with Reload Form, it can support workflows where, after submission, the form should pull in data from the latest entry. Gravity Wiz gives an example showing that Reload Form respects this population behavior during reload. In practice, that is useful in chains where the user or operator repeats part of the data and the system needs to show the latest relevant context.

The difference between Preserve Values and Easy Passthrough is this: Preserve Values is focused on values from the previous submission of the same form, while Easy Passthrough is responsible for transferring data between forms or entries according to a defined configuration. If the task is simple, do not overcomplicate it with Easy Passthrough. If the task spans multiple forms, do not try to solve it with Preserve Values alone.

How to decide which fields should remain

Create a field map with three groups: always clear, okay to preserve, and must be repopulated fresh. A visitor's contact details on a shared device should almost always be cleared. Operator-only internal values, a request category, or a selected location may be preserved. Dynamic fields that depend on fresh entries should go through their population behavior again. That kind of map keeps the setup from turning into guesswork.

A Map of the Built-In Behaviors Worth Configuring Deliberately

Gravity Forms Reload Form does not have many settings, but each one affects a real workflow. Mistakes here rarely look like "the plugin is completely broken." More often the failure is subtle: the user does not understand the link, the form comes back too quickly, old personal data stays on screen, a dynamic list does not update, a popup reopens in the old state, or cache serves outdated markup. That is why it helps to break the product down into individual behaviors before rollout.

This map helps you avoid missing the cause-and-effect chain. For each behavior, there is a place to configure it, an admin input, a product action, a visible outcome, a verification method, a failure symptom, a safe fix, and a limitation. This approach is especially useful for agencies and in-house teams where one person builds the form, another configures the page, a third manages cache, and a fourth signs off on the result.

Behavior 1: the merge tag becomes a working link

Configuration point: the confirmation message of a specific form. The administrator enters text such as {reload_form:Add the next record}. The product replaces the merge tag with an HTML link in the confirmation. The visible outcome is that the user sees a clear link after a successful submission and can bring the form back without a page reload.

Verification requires two submissions in a row. The first should create an entry and display the link. Clicking the link should bring the form back. The second submission should create a new entry. Failure symptom: the link does not appear, appears as plain text, or does not bring the form back. The fix starts with checking the active confirmation, the merge tag syntax, and AJAX embedding. Limitation: the merge tag works in a message confirmation, not as a universal redirect mechanism.

Behavior 2: automatic reload controls the pause after success

Configuration point: the Reload Form section in the form settings. The administrator enables automatic reload and sets a delay. The product waits for the specified time after the confirmation and then returns the form. The visible outcome is that the confirmation appears long enough to be seen, and then the form becomes ready for the next entry.

Verification should reflect the real user. At an internal desk, it may be enough to confirm that the operator has time to notice the success state. On a public form, make sure a person has time to read the message. Failure symptom: the message disappears before the user understands what happened, or the form comes back so late that it slows the workflow. The fix is to change the delay or replace automatic reload with a manual link. Limitation: automatic reload should not remove an important instruction, request number, or link the user still needs.

Behavior 3: Preserve Values saves typing but changes the privacy risk

Configuration point: the Reload Form options for the form. The administrator enables Preserve Values from previous submission. The product returns the form with the previous values still in place. The visible outcome is that the user sees prefilled fields after reload and only needs to change what is different in the next entry.

Verification needs to happen field by field, not just by checking whether "the form came back." First submit a record with a test email and phone number, then check whether those values remain after reload. On a shared device, that outcome is usually not acceptable. Failure symptom: the previous user's personal data is visible to the next person. The fix is to disable Preserve Values or clear specific fields using a confirmed Gravity Wiz approach. Limitation: complex fields such as checkboxes and file uploads need separate testing because their values are stored and displayed differently from a regular text input.

Behavior 4: dynamic population recalculates the current context

Configuration point: the combination of Reload Form with Populate Anything or Easy Passthrough. The administrator configures dynamic population rules or passthrough behavior, and Reload Form brings the form back after submission. The product should apply the latest values again during reload. The visible outcome is that choice lists, prefilled values, or data from the latest entry reflect the current state.

Verification requires a controlled change in the data source. For example, add an entry that should appear in the dynamic list, or change the value being passed by Easy Passthrough. After reload, check whether the form updated. Failure symptom: the form comes back but still shows old choices. The fix is to check the population rules, user or session context, Cache Buster, and page cache. Limitation: Reload Form does not make a data source "live" on its own. It only brings the form back and allows the connected mechanisms to populate fields again.

Behavior 5: modal close should reset the popup state

Configuration point: the JavaScript callback or event of the specific modal plugin. The administrator or developer provides the modal selector and form ID. Through the Reload Form object, the product restores the form when the popup closes. The visible outcome is that the next time the modal opens, the user sees the form instead of the previous confirmation.

Verification should include every way the window can be closed: the close icon, the overlay, the Esc key, and any programmatic close action if one is used. Failure symptom: reload works for only one close method or not at all. The fix is to bind to the modal library's event rather than a visual close button and to replace the sample IDs with real ones. Limitation: every modal plugin has its own events, so a Popup Maker snippet cannot be copied into another library without adaptation.

Behavior 6: Cache Buster separates a fresh form from a cached page

Configuration point: the shortcode, a block-related filter, or global Cache Buster rules. The administrator decides which form or page needs to load fresh. Cache Buster loads the form markup through AJAX so page cache does not serve an outdated form. The visible outcome is that the page stays fast while the form and its dynamic elements do not get stuck in an old state.

Verification: compare the form with cache disabled and with cache enabled. If Reload Form is stable without cache but breaks with cache, the cause is not the merge tag. Failure symptom: stale choices, empty AJAX responses, the confirmation showing up in an unexpected location, or a success message appearing in a "blank" state. The fix is to apply Cache Buster selectively, exclude the form from optimization, or adjust the cache plugin. Limitation: Cache Buster is not the same thing as AJAX submission; it is an extra layer for loading the form.

This behavior map is for making decisions: if the problem is link generation, go to the confirmation; if it is data freshness, go to dynamic population and cache; if it is popup behavior, go to the modal event; if it is privacy, go to Preserve Values and field clearing.

Practical Use Case: A Registration Form at a Desk or Operator Station

Let us look at the use case where Gravity Forms Reload Form really shines. There is a WordPress site, Gravity Forms is installed, and a form called "Visitor Registration" has already been created. A staff member at the front desk fills it out: name, phone or email, visit type, and an admin note. After each submission, the staff member needs to add the next visitor right away. The page should not fully reload because that interrupts the flow of work and may send the user back to the top of the page.

Goal

Get a form that shows a short confirmation after a successful submission and then returns to input for the next record. For a front desk serving different visitors, use a clean form without preserving personal fields. For an internal operator, you may preserve an internal category if that is confirmed by the workflow and does not expose someone else's data.

Preparation

• Gravity Forms is installed and the form is already creating entries.
• Gravity Forms Reload Form is activated through Spellbook or manual installation.
• The form is placed on the page through the Gravity Forms block, shortcode, or a PHP call with AJAX enabled.
• The confirmation is configured as a message, not a redirect.
• Page cache is not interfering with the form, or Cache Buster or an exclusion rule has been prepared for the form.

Setup steps

1. Open the "Visitor Registration" form in the WordPress admin area.
2. Go to Settings and then to Confirmations.
3. Open the confirmation that should run after a standard successful submission.
4. Make sure the confirmation type is an on-page message.
5. Insert a short success message and the merge tag: {reload_form:Add the next visitor}.
6. If you want the automatic mode, open the form settings, find the Reload Form section, and enable automatic reload with a delay long enough for the confirmation to be read.
7. Do not enable Preserve Values for personal fields on a shared device. If the operator only needs to preserve an internal category, first test a separate clearing method for personal fields.
8. Save the settings and open the form page as a regular user.

Verifying the outcome

Make several test submissions in a row. The entries list should show separate records, and the form should return after each successful submission. If you enabled a manual link, make sure the link text is clear and does not look like an external link. If you enabled a timer, make sure the confirmation message stays visible long enough.

After that, check email notifications if they are enabled. Reload Form should not cancel notification feeds. If notifications are not arriving, the problem is usually not Reload Form, but the notification settings, SMTP, conditional logic, or the WordPress mail stack. Do not mix reload troubleshooting with email delivery troubleshooting.

One important detail: repeat submission and duplicate protection

A repeat form speeds up data entry, but it also increases the chance of accidental duplicates. If the operator clicks Submit twice before the form returns, or if someone sends very similar data several times, the entries list may contain similar records. Gravity Forms and related add-ons can handle submission limits separately, but Reload Form itself is not an anti-duplicate filter. If duplicates are critical, design a separate uniqueness check, submission limit, or manual review step.

Practical takeaway: first get repeat submission working correctly on a test form, then add limits, dynamic population, cache exclusions, and modal behavior. That makes it much easier to find the real cause when something breaks.

How to Design the Confirmation So the Reload Does Not Confuse Users

In most UX failures, the issue is not the reload itself but a weak confirmation message. The user submits the form, sees "Thank you," and a link next to it. If the link text does not explain the action, some people will read it as a link to another page, some as a resubmission of the previous entry, and some as a reset. That is why the Reload Form confirmation should be written like a small working state, not like random text that appears after clicking Submit.

A good confirmation has three parts: status, context, and the next available action. The status says the record was saved. The context explains what happens next, if that matters. The next action offers a way to start a new entry or return to the form. For repeat internal forms, the context can be brief. For public forms, it should be clearer because the user does not know the site's internal workflow.

A pattern for meaning, not a fixed text template

You do not need to copy the same phrase into every form. For a consultation request form, a natural message would be: "Your request has been submitted. We will contact you using the details you provided. {reload_form:Submit another request}". For a registration desk, it is better to say: "Record saved. {reload_form:Add the next visitor}". For a callback request form in a popup, you might use: "Thanks, your request has been received. {reload_form:Send another request}".

The difference may seem small, but it reduces false expectations. If the user sees "Add the next visitor," they understand that the previous entry has already been submitted and the next action creates a new record. If they see "Reload Form," they are left to guess.

What not to put in the confirmation

Do not write long instructions if automatic reload is enabled with a short delay. The user will not have time to read them. Do not display personal data from the previous submission on shared devices. Do not place the reload link next to an important payment, download, or account link if the user is supposed to click that one instead. Do not use two equally prominent buttons without explanation, such as "Continue" and "Submit Another," when the next paths are fundamentally different.

You should also avoid wording that makes reload sound like it cancels the submission. Phrases like "Clear and try again" or "Go back" can sound like error recovery rather than a new submission. For a successful submission, verbs like "add," "fill out," and "submit another" are usually clearer.

Conditional confirmations and different outcome paths

If the form uses conditional confirmations, create a separate map of outcomes. For example, a normal request may stay on the page with a reload link. A request marked as a high-priority consultation may send the user to a separate page with detailed instructions. A request with an invalid choice may show a message without reload if manual review is required. The important part is that the reload link should appear only where it does not interfere with the business logic.

Test each branch separately. Submit test data that triggers the first confirmation, then the second, then the third. If the reload link appears in the wrong branch, the user may start the next entry before completing the step they actually need. If it does not appear in the working branch, the operator loses speed.

Confirmation and analytics

On AJAX forms, the success state may not be accompanied by a new page view. If you count conversions by visits to a separate thank-you page, switching to a message confirmation with a reload link changes the analytics model. For forms like this, it is better to track the successful submission event rather than just a URL. That is not a feature of Gravity Forms Reload Form itself, but it is a direct consequence of the UX choice: the user stays on the same page and may submit multiple entries in a row.

For an internal form, analytics may not matter, but the entries log does. For a public form with paid traffic, tracking should be aligned in advance. Otherwise, after Reload Form is introduced, marketing may see fewer thank-you page views even though the number of entries stayed the same or increased.

Verifying the Outcome: Entries, Notifications, Dynamic Data, and Retesting

After configuring Reload Form, it is not enough to see the form come back visually. You need to verify the full data path. The Gravity Forms entry should be created, notification feeds should run, dynamic fields should update, and the repeated submission should create a new record. If you skip that step, you can end up with a nice reload experience that hides a broken business workflow.

Checking entries

Open the entries list for the specific form. Submit the first test entry, then reload the form and submit a second entry with at least one different value. The entries list should contain two records. Each should have its own values, submission time, status, and Gravity Forms metadata. If the second submission does not appear, look for a problem in the submit flow. If it does appear but the values are unexpectedly identical, check Preserve Values, browser autofill, and dynamic population.

For forms with file uploads, also check the files in the entry details. Reload Form should not create the impression that a file from the old submission is automatically attached to the new one. If Preserve Values or a custom clearing snippet affects file upload fields, test them separately and carefully.

Checking notifications and feeds

If the form sends emails, CRM feeds, webhooks, Slack notifications, or another integration, perform at least two repeat submissions. The first verifies the basic submission. The second confirms that reload does not break the next cycle. Ideally, use different email addresses or different test values so the messages are easy to tell apart.

If a notification arrives only for the first entry, the problem may be conditional logic, an anti-duplicate rule, the external CRM, or custom code. If no email arrives at all, troubleshoot SMTP and Gravity Forms notifications. If emails do arrive but contain old values, check dynamic fields and Preserve Values.

Checking dynamic choices

For a form that uses Populate Anything, create a controlled test. For example, the dropdown might show available shifts, records, staff members, or categories. Change the source so the list should update after the first submission. Then submit the form, reload it, and see whether the dropdown changed. If the list is still old, temporarily disable page cache and test again. If the list is fresh without cache, configure Cache Buster or an exclusion rule.

For Easy Passthrough, verify the user or session context. If passthrough uses the latest entry from the logged-in user, a guest test will not produce the same behavior. If passthrough sends data through a token, verify that the confirmation, redirect, or session still carries the expected context. Reload Form may honor population behavior, but it will not fix an incorrect passthrough configuration.

Checking the form's visual state

After reload, check more than just values. Make sure validation messages are gone, the submit button is unlocked, progress indicators in a multi-page form return to the expected state, hidden fields stay hidden, and conditional sections are displayed according to the rules. If the form was on the second page of a multi-page flow, decide whether it should return to the first page. That behavior should be tested separately because multi-page forms carry more client-side state.

If the form uses a Gravity Forms theme framework, check the styling of the confirmation and the reload link. Gravity Forms publishes selectors for the confirmation wrapper and message. For clean styling, CSS is usually enough, but if you add a class through gprf_reload_link, make sure the theme styles do not make the link hard to see or cause another element to overlap it.

Documenting the result for the team

In production projects, it helps to leave a short record: form ID, page, embed method, confirmation branch, reload mode, Preserve Values, dynamic population, cache rule, popup rule, test values, and expected result. That is not bureaucracy. If someone changes the cache plugin, page builder, or text confirmation a few months later, that record quickly shows which conditions Reload Form depends on.

A minimal test note can be simple: "Form 7, page /registration, Gravity Forms block with AJAX enabled, Default Confirmation contains reload tag, Preserve Values off, Cache Buster on, Popup Maker not used, two test entries created successfully." That is enough to keep the next administrator from starting the investigation from scratch.

Team Roles: Who Owns What During Rollout

Gravity Forms Reload Form may look like a small Perk, but rolling it out often touches several roles. If the site owner, editor, and developer all work without a shared understanding, the setup starts to drift: the editor changes the confirmation, the developer fixes the popup, the administrator enables cache, and the operator complains that the form is showing old data again. Clear ownership helps you roll out the product without accidental conflicts.

WordPress administrator

The administrator is responsible for installing Spellbook or the manual ZIP package, activating GF Reload Form, handling updates, and managing permissions. They should not paste the license key into task text, third-party chats, or public snippets. Their responsibility is to make sure the product is active, compatible with the installed environment, and available in the form.

If the Perk is not visible after installation, the administrator should check Gravity Forms activation, Spellbook status, user permissions, and the plugin list. Only after that does it make sense to hand the issue to a developer. Otherwise, the developer may start looking for a JavaScript issue when the product is simply not activated.

Editor or form owner

The editor is responsible for the meaning of the confirmation: what the user should be told, where the reload link should go, whether an automatic delay is needed, and which conditional confirmations should offer another submission. They also decide whether values may be preserved. That is a business decision, not just a technical one. A developer can explain the risks, but should not decide on their own whether personal data may remain on a shared tablet.

It helps if the editor has a list of standard phrases for different forms. But each phrase should match the action. For registration: "Add the next participant." For an internal request: "Create a new request." For a public contact form: "Submit another request." The more precise the wording, the fewer questions users will have.

Developer or technical specialist

The developer is responsible for non-standard containers, popup callbacks, custom elements, class styling through filters, JavaScript optimization exclusions, and conflict-heavy builder scenarios. They should not edit the Gravity Forms core, Reload Form files, or the theme directly. Safe places for changes are a child theme, an mu-plugin, Code Snippets, documented filters, and cache plugin settings.

If a snippet is needed, the developer should document its purpose, form ID, installation location, rollback method, and verification step. For example: "Add classes to the reload link for form 7 through gprf_reload_link; rollback by disabling the snippet; verify that the link still triggers reload after two submissions." That lowers the risk of a snippet losing its owner and getting in the way of future updates.

Operator or internal user

The operator validates the real working pace. Technically, the form may work correctly, but the automatic reload delay may feel awkward, the confirmation text may be too long, or preserving values may actually be necessary for batch entry. That is why, after the technical test, the operator should run through a real sequence of several records. Their feedback will show whether the delay, link text, or Preserve Values setting needs to change.

It is especially important to teach the operator not to click Submit again before the confirmation appears if the form processes a record more slowly than usual. If the workflow needs protection against accidental duplicates, add a separate rule or UX lock rather than assuming reload will solve every duplicate on its own.

Modal Windows, Popup Maker, and Non-Standard Containers

A form inside a popup behaves differently from a form on a regular page. After submission, the user will often close the window. If the form is not reloaded, the next time the popup opens it may still show the old confirmation message. Gravity Wiz documents a separate approach for modal windows: enable Reload Form, configure automatic reload with no delay or call reloadForm in the modal close callback, and then bind the code to the specific popup library.

The official examples include Magnific Popup, Fancybox, and Popup Maker. Popup Maker uses its own popup close event, while Magnific and Fancybox use their own callbacks or close events. The overall idea is the same: after the modal closes, the script finds the window.gwrf_FORMID object and calls reloadForm() if that object exists. This is not universal magic for every popup plugin. It is a binding to the specific event of a specific library.

When modal-close reload is better than a reload link

If a user submits the form and immediately closes the popup, they may never click the reload link at all. When that happens, the next time the popup opens it is still stuck in the confirmation state. Reload on close solves exactly that problem: it resets the form between modal openings. For a marketing popup with a short lead form, that is convenient. For a form whose confirmation contains an important link or instruction, however, automatic reload on close may be a questionable choice because the user loses that message when the popup closes.

How to adapt it to your modal

Do not copy a snippet without understanding three identifiers: the form ID, the modal selector, and the modal close event. In Gravity Wiz examples, the form ID is shown as a number that needs to be replaced with your own. Popup Maker has its own popup IDs, and other libraries will use different events. If the selector is wrong, the code simply will not run. If the form ID is wrong, the window.gwrf_FORMID object will not be found.

There is also a separate path for non-standard containers: the gprf_replacing_elem filter, which lets you define the element that gets replaced during reload. This is useful when the form is not inside a normal page structure or when the wrapper is created by a page builder. But that snippet should only be added after basic reload already works in a standard container. Otherwise, you end up debugging both Reload Form and the DOM structure at the same time.

Multiple instances of the same form on one page

Gravity Wiz warns that Gravity Forms does not natively support multiple instances of the same form on the same page as a standard use case. GP Reload Form has an experimental snippet that can reload all forms with the same ID, but that is already an edge case. If you can avoid placing multiple copies of the same form on one page, do so. If you cannot, test every submission, every confirmation, and every reload separately.

For editors, the key point is different: do not place the same AJAX form in a page builder block, a popup, and a sidebar at the same time unless you fully understand how Gravity Forms and Reload Form will identify the correct container. First simplify the page to one instance of the form, get it working reliably, and only then expand the setup.

Cache, Script Optimization, and Theme Compatibility

Gravity Forms relies on HTML markup, JavaScript, hidden fields, a nonce, an AJAX endpoint, and the required assets being loaded. Cache and script optimization can break that chain. Gravity Forms addresses cache and script optimization issues in its own documentation, and Gravity Wiz recommends Cache Buster for dynamic forms so you do not have to disable page cache entirely.

That is especially noticeable with Reload Form because the form not only has to submit, it also has to return correctly. If the page serves stale markup, if scripts are bundled in the wrong order, if jQuery is deferred to the footer in a conflicting way, or if the page builder changes the container after the popup opens, reload may look "broken" even though the Perk itself is installed correctly.

What to check when cache is enabled

• The page with the form opens without JavaScript errors before submission.
• AJAX submission works on an uncached page or in a mode where cache is temporarily disabled.
• After cache is cleared, the confirmation message appears correctly.
• The reload link or timer brings the form back without another full page load.
• Dynamic values really do update after reload if the form uses Populate Anything or Easy Passthrough.

If everything works without cache but breaks with cache, do not start rewriting Reload Form. Configure cache exclusions or Cache Buster first. Gravity Wiz documents an approach where the form loads via AJAX outside page cache while the rest of the page continues to use caching. That is much cleaner than turning off cache for the entire site.

JavaScript optimization

Minification, deferred loading, and JavaScript bundling can change script execution order. Gravity Forms and its add-ons need to initialize at the right time. If the reload link appears after optimization is enabled but does not work, check the browser console. Errors such as an undefined object, blocked script, missing jQuery, or a popup library conflict point to the JavaScript layer, not to the merge tag text.

On a production site, it is usually better to exclude the relevant Gravity Forms, Gravity Wiz, and popup library scripts from aggressive optimization than to try to compensate for the problem with extra snippets. After every change, clear page cache, CDN cache, and browser cache. Otherwise, you may still be testing an old JavaScript build.

Theme and page builder compatibility

The theme and page builder can affect the form container, the styling of the confirmation message, the visibility of the reload link, and modal behavior. Gravity Wiz changelogs and weekly updates include mentions of Reload Form compatibility with Elementor Builder, the Gravity Forms block, and Cache Buster. That does not mean every builder breaks the product. It means that on a complex page, you need to test the exact combination: form, theme, builder, popup, cache, and script optimizer.

If reload works on a standard WordPress page but not inside a complex builder block, create a minimal test page with the same form. That will show you where the problem boundary is. Do not change the production form blindly until you can reproduce the issue on a simple page.

Safely Adapting the Reload Link to Match Your Site Design

The Gravity Wiz documentation includes the gprf_reload_link filter, which allows you to change the HTML string of the reload link. That is useful if the link should look like a theme button, receive an extra CSS class, or fit into an existing confirmation style. This approach is safer than editing plugin files because it relies on a public extension point and survives updates.

Below is an author-created adaptation based on the documented gprf_reload_link filter. It adds classes to the link for only one form. The code can go into Code Snippets, a small mu-plugin, or the child theme's functions.php. Before using it, replace 7 with your own form ID. If you are not sure what the ID is, open the Forms list in Gravity Forms and check the form number in the admin area.

add_filter( 'gprf_reload_link', function( $reload_link, $form ) {
    $target_form_id = 7;

    if ( (int) rgar( $form, 'id' ) !== $target_form_id ) {
        return $reload_link;
    }

    $extra_classes = 'button button-primary gprf-repeat-link';

    if ( strpos( $reload_link, 'class="' ) === false ) {
        return str_replace( '<a ', '<a class="' . esc_attr( $extra_classes ) . '" ', $reload_link );
    }

    return preg_replace(
        '/class="([^"]*)"/',
        'class="$1 ' . esc_attr( $extra_classes ) . '"',
        $reload_link,
        1
    );
}, 10, 2 );

Verification is simple: submit the form, inspect the reload link HTML in the browser tools, and make sure the classes were added. Then confirm that the link still triggers a reload instead of turning into a normal navigation link. If the link stops working, disable the snippet and go back to the default output. Rolling back should be as easy as deactivating the snippet.

When it is better to avoid PHP

If you only need to change the color, size, or spacing of the existing link, theme CSS is usually enough. Gravity Forms publishes CSS selectors for the confirmation message, including the wrapper and links in the Orbital theme. First check whether the appearance can be adjusted with CSS alone. A PHP filter is needed when the theme expects a specific class on the link or when button-like styling is built around class names.

Do not use JavaScript to replace the reload link HTML if a filter solves the problem. JavaScript may run later than the moment the user sees the message, may conflict with an optimizer, and makes troubleshooting harder. The filter changes the link server-side when the HTML is generated, so the result is more stable.

The limits of safe customization

Do not change the URL, data attributes, or internal behavior of the reload link unless there is a real need. Adding a class is safe because it does not break the link action. Replacing the href, removing attributes, or wrapping the link in complex theme components may break Reload Form's JavaScript. If you need a fully custom element, look at the official custom element snippet and test it on a copy of the form.

If the Form Does Not Reload: Symptom-Based Troubleshooting

Problems with Gravity Forms Reload Form almost always fall into a few common chains: AJAX is not enabled, the confirmation does not contain the correct merge tag, JavaScript is not running, the form is inside a non-standard container, cache is serving stale markup, or related add-ons are changing values in unexpected ways. Troubleshooting should move from simple checks to more complex ones.

The reload link does not appear in the confirmation

Symptom: after submitting the form, you see a normal success message, but there is no "submit another" link. A likely cause is that the merge tag is missing from the active confirmation, entered incorrectly, or another conditional confirmation was triggered. Open the confirmation settings and check the exact branch shown after the test submission.

Fix: insert the merge tag into the correct message, save the form, clear the cache, and submit again. Use simple text such as {reload_form:Submit another request}. Do not put the merge tag into a redirect URL and do not expect it to appear on a separate thank-you page.

The link is there, but clicking it does nothing

Symptom: the confirmation message contains the reload link, but the form does not return. The first thing to check is whether AJAX is enabled for the form. Gravity Wiz documentation states that Reload Form works with AJAX forms. If the form is embedded without AJAX, enable it in the Gravity Forms block, shortcode, or PHP call.

If AJAX is enabled, open the browser console. JavaScript errors, a jQuery conflict, scripts blocked by an optimizer, or a missing window.gwrf_FORMID object can stop the reload from running. Temporarily disable JavaScript bundling and deferred loading for the form page, clear the cache, and test again. If it works without optimization, configure exclusions instead of rewriting the confirmation.

The form inside a popup shows the old message when reopened

Symptom: the user submitted the popup form, closed the window, opened it again, and saw the old confirmation message instead of the form. The cause is that reload is not bound to the modal close event, or the wrong selector was used. For Popup Maker, Fancybox, and Magnific Popup, use the matching official Gravity Wiz example and replace the popup ID and form ID with your actual values.

Verification: open the popup, submit the form, close the popup, and open it again. If the form has returned, the setup is working. If not, check the close event, the form ID, and whether the Reload Form object exists on window. Do not bind reload to a click on the close button if the modal library can also close by overlay click, the Esc key, or a programmatic event. Using the library's own event is more reliable.

Old values remain after reload

Symptom: the form comes back, but some fields are still filled with data from the previous submission. A likely cause is that Preserve Values is enabled, dynamic population is pulling in the latest entry values, or the browser is filling values through autofill. On a shared device, that is a risk. Disable Preserve Values, check dynamic population, and test the form in a private browser window.

If you need to preserve only some values, do not solve that with random JavaScript that clears inputs after the form is shown. It is better to use the officially documented Gravity Wiz approach for clearing specific fields with Preserve Values, or a careful server-side adaptation. For file upload and checkbox fields, make sure to test separately because those field types store values in a more complex way.

Dynamic fields do not update

Symptom: the reloaded form still shows an old list of choices or an old value even though the data source has changed. A likely cause is page cache, Populate Anything request cache, an incorrect dynamic population setup, or a Cache Buster conflict. Test the form without page cache and without aggressive script optimization. If the fresh page works correctly, configure a targeted cache bypass.

Also verify that the dynamic behavior really depends on a fresh source. If Easy Passthrough is configured to use the latest entry from the current user, a guest session test may not match a logged-in user test. Different session, user, and entry contexts can produce different values, and that is expected.

An entry is created after submission, but notifications are not sent

Symptom: reload works, entries appear, but the email notification does not arrive. This is not a typical Reload Form issue. Check the notification settings, notification conditional logic, SMTP, the spam folder, and your mail plugin logs. Reload Form returns the form after the confirmation, but it should not replace the delivery stack.

Rollback test: temporarily remove {reload_form} from the confirmation and test a regular submission. If the notification still does not arrive, the issue is outside Reload Form. If notifications work without reload, check whether you added a custom JavaScript or PHP snippet that interferes with the confirmation or submit flow.

The form breaks only inside a builder or on one specific page

Symptom: everything works on a simple WordPress page, but reload breaks inside a builder, tab, accordion, popup, or complex layout. The cause is often a container that gets redrawn by the builder script or a form that is hidden during initialization. First test on a standard page. Then move the form into the target container and add only one complicating factor at a time.

If the container really is non-standard, look at the official gprf_replacing_elem snippet. It lets you define which element should be replaced during reload. But use it as a precise fix, not as a universal cure for every builder-related problem.

Questions That Come Up Most Often During Setup

Can I use Gravity Forms Reload Form without AJAX?

For the core use case, showing the form again without a full page reload, AJAX is required. Gravity Wiz lists that as a basic condition in its documentation. If the form submits through a standard page reload, the reload link will not solve the problem the way you expect. Enable AJAX in the form embedding method and check the confirmation message.

Where exactly should I place {reload_form}?

The merge tag goes into the confirmation message for the target form. Open Settings, then Confirmations, choose the message confirmation, and add a line such as {reload_form:Submit another request}. If the form has multiple conditional confirmations, insert the tag only into the branches where repeat submission is actually needed.

Can the reload happen automatically?

Yes. The form settings include a Reload Form section where you can enable automatic reload and set a delay. Automatic mode works well for desks, kiosks, and internal forms with a short confirmation. For public forms with important instructions, it is better to keep a manual link or choose a delay long enough for reading.

What does Preserve Values do?

This setting returns the form after reload with data from the previous submission still filled in. It is convenient for batches of similar internal records, but risky on shared devices and public forms that contain personal data. In most cases, it is better to clear the form by default and only enable preservation after explicitly deciding which fields may remain.

Why does the popup still show the confirmation message after it is closed?

Because form submission and closing a modal are two different events. In a popup setup, reload needs to be tied to the close event of the specific modal library. Gravity Wiz publishes examples for Popup Maker, Fancybox, and Magnific Popup. Check the form ID, popup selector, and close event.

Will this plugin help if no emails are sent after the form is submitted?

No, that is a different problem. Reload Form is responsible for bringing the form back after a successful submission. If entries are created but notifications do not arrive, check the notification settings, SMTP, notification conditional logic, and mail logs. Do not try to solve mail delivery problems through reload settings.

Can I use it together with Populate Anything?

Yes, that is one of the confirmed Gravity Wiz use cases. Fields dynamically populated through Populate Anything should update on reload. But if the values look stale, check cache, the dynamic population rules, and the user context.

Is there a free one-line JavaScript replacement?

Sometimes you can write custom JavaScript on the confirmation event, but then you are responsible for maintaining that code. It needs to account for AJAX, the DOM container, cache, modals, repeat submissions, and future Gravity Forms updates. Gravity Forms Reload Form is convenient because it already provides a built-in reload function, a merge tag, a timer, and related snippets for common use cases.

When Gravity Forms Reload Form Is the Right Choice

Gravity Forms Reload Form is worth using when you already have Gravity Forms, the form submits through AJAX, and after a successful submission the user needs to start a new entry quickly on the same page. The strongest use cases are internal operators, registration desks, repeat requests, popup forms, forms with dynamic values, and pages where a full reload breaks the work rhythm.

Before rollout, do not check only the reload link itself. Make sure the confirmation message is clear, AJAX is enabled in the actual embed method, entries are created separately, notifications work, cache is not serving a stale form, and Preserve Values is not exposing personal data where different people use the same form. A good Reload Form setup is not just one merge tag. It is a verified chain of "submission -> confirmation -> reload -> new entry."

If the form is one-time only, if a redirect is required after submission, if the user needs time to read the confirmation, or if the real task is passing data between different forms, do not enable Reload Form automatically. In those cases, it is better to use built-in confirmations, Easy Passthrough, Populate Anything, Cache Buster, or separate custom logic for the specific need.

For a safe starting point, configure the product on a copy of the form, perform two or three test submissions in a row, check the entries, and only then move the settings to the live page. Once the chain is confirmed, you can move on to downloading, installing, and final testing of the product on your site.