Gravity Forms Preview Submission - WordPress Plugin

A Guide to Setting Up Gravity Forms Preview Submission to Review a Form Before Sending It

Gravity Forms Preview Submission is not about dressing up a form. It solves a very practical problem: letting users review their answers before they click the final submit button. In this guide, we will walk through how to add that step to a multi-page form, which merge tags to use, how to format the final review screen, what to check after installation, and where preview logic usually breaks down.

This guide is written for site owners, web admins, and developers who already use Gravity Forms and want to reduce bad submissions, incorrect orders, application errors, or registration mistakes. It does not cover purchasing or licensing. The focus is on using the installed plugin in a real workflow, verifying the result, and making safe, reversible refinements without touching the WordPress core, Gravity Forms core, or the plugin itself.

One important detail up front: the preview step does not replace the post-submission confirmation, and it is not a separate submission storage system. It runs before the final entry is created, helps users catch mistakes, and when configured well, makes long forms easier to understand. That is why this article separately covers page order, the HTML field, rendering {all_fields}, hidden fields, default values, compatibility with related Gravity Perks, and troubleshooting cases where the final summary does not appear.

How Preview Works in a Multi-Page Form

The logic behind Gravity Forms Preview Submission revolves around two Gravity Forms elements: a multi-page form and an HTML field. Users complete fields on earlier pages, move to the last page, and see a summary of the data they entered. Technically, that summary is built with entry-based merge tags, which the plugin allows you to use inside the HTML field content and in the Default Value setting for fields on later pages.

A standard Gravity Forms HTML field is meant to display text or markup inside the form. By itself, it is not saved as part of the entry and is not treated as an input field in the default workflow. Gravity Forms Preview Submission makes that field much more useful: you can now display values from fields the user has already completed and build a "review your details before submitting" screen. The fastest option is to insert the {all_fields} merge tag, which generates a table of submitted field values.

For users, this feels like an extra step between filling out the form and sending it. For the form administrator, it is still a normal Gravity Forms structure: pages, fields, Next, Previous, and the final Submit button. It is important not to confuse this step with a confirmation. The confirmation appears after a successful submission, while the preview appears before it. That is exactly why it is useful for submissions where a mistake in one field can derail the whole process: full name, address, selected package, booking date, attendee list, comments, uploaded files, or billing details.

The most reliable workflow looks like this:

1. Create or open a form in the Gravity Forms editor.
2. Split the form into pages using the Page Break field if it is not already multi-page.
3. Add an HTML field to the last page to display the summary.
4. Insert the required merge tags into the HTML field content, such as {all_fields} or individual tags for selected fields.
5. Test the form as a normal visitor: complete the earlier pages, go to the preview step, correct an error using the Previous button, submit the form, and review the entry in the admin panel.

Key check: if the form has only one page, the preview step usually will not deliver the intended result. Add a Page Break field and place the HTML summary field on a page that comes after the input fields.

Where Gravity Forms Preview Submission Is Actually Useful

This plugin works best in forms where users enter a lot of information and should make a deliberate final check before submitting. That does not mean ecommerce only. A review screen is useful for event registrations, booking forms, candidate applications, service request forms, education inquiries, contact forms with attachments, and long surveys.

In a short contact form with three fields, the extra step may be unnecessary. Users can already see everything they entered on one screen. But the more pages, conditional branches, and important fields a form has, the higher the risk that someone will make a mistake, miss a selected option, or submit outdated information. A preview step helps reduce that risk without building a separate user portal.

Application and Intake Forms

In application and intake forms, the preview step is especially useful because of simple human error. Users often return to a form after a pause, copy information from documents, update a phone number, or attach a file. A final screen with clear grouping gives them a chance to calmly review what they entered. If the form is used for candidate screening, enrollment, or registration for a private event, this step can reduce follow-up emails for clarification.

Orders, Quotes, and Bookings

If the form includes fields for selecting a service, number of attendees, date, time range, address, or a custom price, the preview functions like a "review your order" screen. It does not turn Gravity Forms into a full shopping cart, but it does let users see the final combination of values before submission. For simple order forms, that is often enough, especially when payment or staff review happens after the request is received.

Forms With Conditional Logic

Conditional logic hides unnecessary fields and makes the form shorter for a specific user. But it also has a side effect: users may forget which answers opened or closed which sections. The preview helps display only the final set of data that actually became part of the flow. In these forms, it is especially important to check that hidden technical fields, system values, or admin-only labels are not being displayed.

When the Product May Be Unnecessary

The plugin may not be the right fit if you need full entry editing after submission, a public applicant dashboard, complex moderation, multi-stage approvals, or persistent entry display on the site. Those use cases require different tools: frontend entry display, entry editing, draft workflows, or user dashboards. Gravity Forms Preview Submission is designed specifically for the step before submission: review, verify, and confirm.

What to Check Before Installation and Activation

Before installation, it is worth checking more than just whether Gravity Forms is present. Review the structure of the actual form. The preview depends on how the form is split across pages, which fields are required, whether conditional logic is in use, which fields are hidden, and which data should not be shown back to the user. If you skip this step, the plugin may install correctly, but the user-facing result may still be weak: the summary may be too long, unclear, or reveal too much.

Minimum Form Preparation

Start with the form, not the plugin. Open it in the Gravity Forms editor and review the field order. If the form is long, the pages should be divided logically: contact details, request details, additional information, review. The preview page should come after all fields the user needs to verify. If some fields appear conditionally, test at least two scenarios: one where the conditional block is shown and one where it stays hidden.

• Check that the form is already multi-page or can become multi-page without hurting the workflow.
• Make sure required fields are validated before the user reaches the last page.
• Identify fields that should not appear in the summary: technical hidden fields, internal statuses, service values, and administrative comments.
• Decide whether you need a full summary via {all_fields} or a custom layout with individual merge tags.
• Check whether the form already uses nearby extensions that change navigation, autosave behavior, page transitions, or dynamic population.

Theme and Cache Compatibility

The preview itself is built inside the form, so problems usually come not from the theme directly but from aggressive JavaScript optimization, page caching on the form page, visual styling conflicts, or nonstandard form output inside a page builder. If the form is embedded in a landing page through a block, shortcode, or builder module, test it in the exact location where users will see it. Do not limit testing to the form editor preview.

On cached sites, it is safer to exclude the multi-page form page from aggressive optimizations if you notice odd symptoms: the Next button does not respond, values do not make it to the last page, the summary shows stale data, or the form behaves differently for admins and guests. There is no need to disable site-wide caching immediately. Start with a targeted check of the form page, script-combining settings, and deferred JavaScript loading.

Data You Should Not Show in the Preview

{all_fields} is convenient for a first pass, but it is not always the right final interface. It can show more data than the user actually needs. If the form includes hidden fields, system values, administrative fields, or technical labels, configure merge tag modifiers or build the summary manually. Users should see what helps them verify the submission, not the form's internal plumbing.

Installation and Initial Testing With Minimal Risk

Installing Gravity Forms Preview Submission is not fundamentally different from installing any other WordPress plugin, but it is best tested on a copy of the form or on a staging page. The reason is simple: even if the plugin works correctly, changing the form structure can affect the user journey, conversion rate, and notifications. What you need is not just activation, but a complete validation pass from the first field to the saved entry in the admin panel.

Activation Order

1. Make sure Gravity Forms is active and the form you plan to change already works.
2. Install and activate Gravity Forms Preview Submission in WordPress.
3. Create a copy of the important form or prepare a test form with a similar structure.
4. Add a Page Break field if the form currently has only one page.
5. Add an HTML field to the last page of the form.
6. Insert {all_fields} or custom HTML markup with individual merge tags into the Content field.
7. Save the form with Update and test it on the public page.

The initial test should be as close to real user behavior as possible. Open the form page in a private window, complete all required fields, move through to the last page, change one value using the Previous button, return to the preview, and confirm that the summary updates. Then submit the form and check the entry, notification, and confirmation.

Why You Should Not Change the Live Form Right Away

The preview step can change the form length and user expectations. For example, if the Next button on the second-to-last page previously led directly to submission, users will now see an extra screen. That is useful, but the button text and explanatory copy should match the new flow. On the page before the preview, it is worth stating clearly that the next step will show a summary rather than submit the data immediately.

Quick takeaway: installation is not complete when the plugin is activated. It is complete when a full user flow succeeds: fill out the form, reach the preview, correct a value, review again, submit, and verify the entry in the admin panel.

Configuring the HTML Field and Merge Tags for a Clean Summary

The main configuration for Gravity Forms Preview Submission does not live in one large settings screen. It lives inside the form itself. You choose the HTML field, open its settings, and build the content for the final step. That makes the product flexible, but it also requires editorial discipline: the summary should be concise, clear, and aligned with the structure of the form.

The Fast Option With {all_fields}

If you want to test the plugin quickly, insert the {all_fields} merge tag into the HTML field's Content. It outputs a summary table of all submitted values. This is a good starting point for testing because it immediately shows whether data from previous pages is reaching the preview screen.

For a production form, modifiers are more common. For example, {all_fields:nohidden} helps remove Hidden fields from the output. If you need raw values instead of human-readable choice labels, you can use the :value modifier. If administrative field labels matter, there is also the :admin modifier. Modifiers can be combined with commas, but before going live, make sure to test the result in the real form.

Custom Markup Instead of a Full Table

For an important form, it is usually better not to leave the summary as a technical table of every field. Create clear groups such as "Contact Information," "Request Details," "Files," and "Comment." Inside each group, insert individual merge tags using the tag picker next to the Content field. That makes it much easier for users to see what they need to review.

Example of a simple HTML field structure:

<div class="gpps-review-box">
  <h3>Review your submission before sending</h3>
  <p><strong>Name:</strong> {Name:1}</p>
  <p><strong>Email:</strong> {Email:2}</p>
  <p><strong>Selected service:</strong> {Service:5}</p>
  <p><strong>Comment:</strong> {Message:7}</p>
</div>

The field IDs in this example are placeholders. In your own form, insert merge tags through the Gravity Forms interface so you do not mistype the field name or number. If a field is renamed or deleted, the custom summary needs to be updated as well.

How to Style the Summary Without Editing the Plugin

The safest way to improve the appearance is to add your own class to the wrapper inside the HTML field and style it with extra CSS from the theme, child theme, or a safe snippets tool. That code does not depend on the plugin's internal files and is easy to disable.

.gpps-review-box {
  padding: 1.25rem;
  border: 1px solid #d8dee8;
  border-radius: 8px;
  background: #f7f9fc;
}

.gpps-review-box h3 {
  margin-top: 0;
}

.gpps-review-box p {
  margin: 0 0 0.65rem;
}

After adding the CSS, open the form on the public page, go to the preview step, and check spacing, long value wrapping, mobile layout, and text contrast. If the styling conflicts with the theme, remove the CSS or narrow the selector, for example by adding a page or form class before .gpps-review-box.

Default Values and Carrying Answers to Later Pages

Gravity Forms Preview Submission has a second important capability that is often underestimated: the plugin adds support for entry-based merge tags in the Default Value setting. That lets you use values entered on earlier pages inside fields on later pages. You do not need this in every form, but in the right scenario it can make the flow much easier to follow.

For example, on the first page the user selects a request type, on the second page they provide details, and on the third page they see a field with a prefilled value or note based on that earlier choice. This is not the same as dynamically populating every possible option. If you need to populate values on the same page, work with choice sets, or pull data from entries, users, taxonomies, or external sources, Gravity Wiz recommends looking at GP Populate Anything. But for carrying a previously entered answer onto the next page, Default Value may be enough.

Where This Technique Makes Sense

A good example is a consultation booking form. On the first page, the user selects a service area; on the second, they enter contact information; and on the last, they see the summary. If you need to insert the selected service area into a text field or explanatory note on the middle page, you can use the earlier field's merge tag in Default Value. The form then "remembers" the user's choice and makes the next steps feel more contextual.

Where It Is Better Not to Overcomplicate Things

Do not use default values as hidden business logic if the result depends on complex conditions, pricing, external data, or frequently updated reference data. In those cases, it is better to use dedicated Gravity Forms features, calculation fields, or separate extensions. The preview step should help users review data, not turn into a hidden calculation engine.

Testing After Configuration

Test every case where a value is supposed to carry forward. Fill in the field on the first page, move ahead, and confirm that the field on the next page received the correct value. Then go back, change the original answer, and test the next page again. If the value does not update the way you expect, do not jump straight to scripts. First, verify the page order, the exact merge tag, and whether the target field is actually located on a later page.

Practical Example: A Request Form With a Final Review Screen

Let us look at a concrete scenario: an agency website accepts consultation requests. The form has three pages. On the first page, the user selects a service and budget; on the second, they enter contact details and a comment; on the third, they see the summary and submit the request. The goal is to give the user a chance to fix a mistake before the entry is created and before the manager notification is sent.

Goal

You want a simple, clear screen that says "Review your request." It should display the name, email, selected service, budget, comment, and a short note that clicking submit will create the request. Technical fields, hidden labels, and internal values should not be shown.

Preparation

Before configuring anything, create a test copy of the form. This is especially important if the form already receives real submissions. In the copy, add three pages using Page Break. You can use clear page names such as "Service," "Contact," and "Review." If you use a progress indicator, make sure the last step is not called "Submit" if users can still go back and edit data there.

Configuration Steps

1. On the first page, add a service selection field, a budget field, and any conditional detail fields you need.
2. On the second page, add Name, Email, phone, and comment fields.
3. On the third page, add an HTML field and open its settings.
4. In the Content field, insert your own markup with individual merge tags instead of a full table of all fields.
5. Add a note that users can return with the Previous button if they spot an error.
6. Save the form and embed it on a test page the same way it will be embedded on the live page.

Example Copy for the Final Page

<div class="gpps-review-box">
  <h3>Review your request</h3>
  <p>If everything looks correct, submit the form. If you found an error, go back and update the information.</p>
  <p><strong>Name:</strong> {Name:1}</p>
  <p><strong>Email:</strong> {Email:2}</p>
  <p><strong>Service:</strong> {Service:3}</p>
  <p><strong>Budget:</strong> {Budget:4}</p>
  <p><strong>Comment:</strong> {Comment:5}</p>
</div>

In your own project, do not copy the field numbers from this example. Insert merge tags through the tag picker so Gravity Forms supplies the correct values. If a field is conditional and sometimes empty, decide whether you want to show a blank line or use conditional output instead. For a straightforward project, it is usually enough to group fields neatly and remove unnecessary technical values.

Expected Result

The user completes the form, sees the summary, and clearly understands what will be submitted. If they go back and change the service, the last step should show the updated service. After the final Submit, the entry appears in Entries, the notification is sent using normal Gravity Forms rules, and the confirmation displays the post-submission response.

A Detail People Often Forget

If the user sees an error on the preview page and needs to return to a specific earlier page, the standard Previous button may not be enough in a very long form. In that case, consider Gravity Forms Multi-Page Navigation. It integrates with Preview Submission and can make it much easier to jump back to the right page. For a short three-page form, though, that extra navigation may be unnecessary.

How to Verify the Result on the Site, in the Entry, and in Emails

Preview testing should cover three levels: the public form screen, the entry in the admin panel, and the notifications. An issue can appear at any of those layers. For example, the preview may look correct, but the notification may send with an outdated set of merge tags. Or the entry may save correctly, while the user saw a hidden technical field in the summary. So do not test only the visual result on the last page.

Checking the Public-Facing Form

Open the form page in a private window. Go through the form multiple times with different data sets: a minimum scenario, a scenario with conditional fields, one with a long comment, and one with empty optional fields. On the last page, check that the summary does not break the layout, long strings wrap properly, empty fields do not create visual noise, and the Previous and Submit buttons are clear.

Checking the Entry

After submission, open Entries for that form. Make sure the entry contains the same values the user saw in the preview. Remember that the HTML field itself is not a saved input field. It displays the summary, but it does not replace the actual form fields. If you need to save a separate final summary string, that is a different task and should be handled with separate logic, not by expecting HTML fields to behave like input fields.

Checking Notifications and Confirmations

Notifications and confirmations in Gravity Forms also use merge tags. After adding the preview step, make sure your manager and user emails are still current. If the email needs the same summary, configure it separately inside the notification. Do not assume the preview HTML will automatically become the email body. These are different contexts, and each one needs its own check for formatting, line breaks, and unwanted fields.

Checking the Mobile View

Multi-page forms are often completed on a phone, even if the administrator configured them on a desktop monitor. Open the last page on a narrow screen and look at how the {all_fields} table behaves. If the table fits poorly, a manual summary built with paragraphs or short blocks will be easier to use. Users should be able to understand what they need to review quickly, not scroll horizontally through a cramped table.

Working Alongside Other Gravity Perks

Gravity Forms Preview Submission is often used together with other Gravity Wiz extensions rather than on its own. That is perfectly normal, but each neighboring extension changes the user journey. One handles page navigation, another draft saving, another dynamic population. If you do not separate those roles clearly, troubleshooting becomes much harder because it is no longer obvious which plugin is responsible for a given symptom.

Multi-Page Navigation

Gravity Forms Multi-Page Navigation is useful when the form is long and users need a faster way to return to the page with an error. The documentation for that extension explicitly describes its integration with Preview Submission: if someone spots a mistake on the final page, page navigation helps them jump back to the correct step without clicking Previous repeatedly. For long applications, intake forms, and order forms, that is a strong combination.

But navigation should be enabled deliberately. If the form is meant to be completed in a strict linear order, overly flexible movement between pages can confuse users or bypass the intended review sequence before final validation. Choose the navigation mode based on the real workflow: completed pages only, from the beginning, or after the user reaches the last page.

Page Transitions and the Soft Validation Limitation

Gravity Wiz notes an important limitation: when Preview Submission is used together with Page Transitions, previews do not work if Soft Validation is enabled. This is not a cosmetic issue. It is a real compatibility condition. If the site already uses animated page transitions and soft validation, test the preview especially carefully. If problems appear, disable Soft Validation first and run through the form again.

Advanced Save & Continue

Advanced Save & Continue solves a different problem: saving and restoring drafts for long forms. It is useful when users may need to stop and return later. Preview Submission handles the final review before submission. These features complement each other, but they are not interchangeable. If the form collects a large amount of information, a strong setup can look like this: the user completes the form in stages, returns to the draft, reaches the last page, reviews the summary, and submits the entry.

Populate Anything and Dynamic Values

If you need to populate values from entries, users, terms, WordPress posts, databases, or external sources, Preview Submission alone may not be enough. Gravity Wiz documentation specifically points to GP Populate Anything for scenarios where values need to be dynamically populated on the same page or where custom values need to appear inside labels. Keep those tasks separate: preview shows what the user has already entered, while dynamic population builds choices and values before or during input.

Safe Enhancements: Styling, Conditional Output, and Localization

After the basic setup, it is natural to want a more polished preview: hide empty lines, highlight important values, translate labels, and adapt the look to the theme. That is a normal stage, but it should be done safely. Do not edit plugin files or add large JavaScript customizations that interfere with form submission. Start with HTML markup, CSS, and documented Gravity Forms and Gravity Wiz capabilities.

Styling Your Own Wrapper

The safest technique has already been shown above: wrap the summary in your own class, such as gpps-review-box, and style only that block. This keeps other forms on the site untouched. If the site has several forms with different visual needs, add a second purpose-based class such as gpps-review-box gpps-review-box--booking or gpps-review-box gpps-review-box--application.

Conditional Output for Individual Lines

Gravity Wiz lists Conditional Shortcode as a related resource for displaying conditional content in confirmations, notifications, and HTML fields used with GP Preview Submission. This is useful when a line should appear only when a value exists or when a specific choice was made. Do not use conditional blocks for complex business logic, but for a clean summary they are a good fit.

[gravityforms action="conditional" merge_tag="{Comment:5}" condition="isnot" value=""]
<p><strong>Comment:</strong> {Comment:5}</p>
[/gravityforms]

After adding a conditional block, test two cases: the field is filled in and the field is empty. If you still see extra spacing when the value is blank, reduce the wrapper or move the condition so it covers the entire paragraph.

Localizing Interface Strings

For translating Gravity Wiz strings, the documentation mentions Loco Translate. That is useful if you need to adapt plugin interface strings for a non-English site. But do not try to translate the actual field names inside the form through translation files if you can change them directly in the Gravity Forms editor. First configure the labels, page names, and button text in the form itself, then handle plugin translations if needed.

Rolling Changes Back

Before adding CSS, conditional blocks, or translations, save a copy of the HTML field content. If the result breaks, rollback should be simple: restore the previous HTML field content, disable the CSS snippet, or remove the translation. Do not create a customization that cannot be removed quickly while the form is receiving real submissions.

Why the Preview May Not Work and How to Find the Cause

Most problems with Gravity Forms Preview Submission are caused not by installation itself, but by HTML field placement, page structure, merge tags, hidden fields, or neighboring extensions. It is best to troubleshoot from simple to complex: start with the form and the page, then check tags, then move on to conflicts and caching.

The Summary Does Not Appear on the Final Step

Symptom

The user completes the form, but no entered data appears on the last page. In some cases, the HTML field is simply empty, or only plain text appears without inserted values.

What to Check

• The form is truly multi-page, and the HTML field is placed on a page after the input fields.
• The HTML field's Content contains a valid merge tag such as {all_fields} or the exact tags for the relevant fields.
• The form was saved after the change and opened on the public page, not just in an old editor window.

How to Fix It

Add a Page Break, move the HTML field to the final page, and reinsert the merge tags using the tag picker. If the form was previously one page, do not expect a full preview workflow without splitting it into steps.

Hidden or System Fields Appear in the Summary

Symptom

The review screen shows technical values, hidden fields, internal statuses, or data the user should not see.

What to Check

Check whether you are using the full {all_fields} output. According to Gravity Forms documentation, this merge tag supports modifiers including :nohidden. But keep in mind that different forms of hidden behavior in Gravity Forms may behave differently, so final testing in the real form is required.

How to Fix It

For a quick fix, try {all_fields:nohidden}. For an important form, it is better to build a manual summary from individual merge tags and avoid outputting system fields altogether. If the site already uses an older snippet for hiding hidden fields, check Gravity Wiz's current recommendation: the older snippet was replaced by a newer approach in the snippet library.

Values Do Not Update After Going Back

Symptom

The user changes a field on a previous page, returns to the preview, but still sees the old value or an incomplete summary.

What to Check

• The changed field is located on a page before the preview HTML field.
• The correct merge tag for that exact field is being used.
• The page is not affected by caching or script optimization that interferes with the multi-page form.
• If you are using the Live Refresh snippet, it is installed correctly and does not conflict with other form logic.

How to Fix It

Start by reducing the form to a minimal scenario: one field on the first page and an HTML field with {all_fields} on the second. If that minimal version works, add the remaining fields and extensions back one at a time. That approach is faster than trying to guess the conflict inside a complex form.

The Preview Conflicts With Page Transitions

Symptom

The form uses animated transitions, but the preview behaves inconsistently on the final step or does not appear at all.

What to Check

Gravity Wiz documentation points to a specific limitation: Preview Submission does not work with Page Transitions when Soft Validation is enabled. So the first test should be disabling that setting, not rewriting the HTML field.

How to Fix It

Disable Soft Validation and test the form again. If the preview starts working, decide what matters more for that specific form: soft validation with animation, or a reliable review screen before submission. For critical forms, a dependable preview is usually the better choice.

No Email Arrives After Submission or the Confirmation Does Not Match the Summary

Symptom

The user sees the correct preview, but the manager email does not arrive, arrives without the expected values, or the post-submission confirmation looks different.

What to Check

Preview, notifications, and confirmations are separate Gravity Forms contexts. The HTML field setup does not replace notification setup. Check Notifications, Confirmations, recipient addresses, merge tags in the email, and WordPress email delivery.

How to Fix It

Configure the email separately and send a test submission. If the real issue is email delivery, handle it like a standard Gravity Forms notification problem: SMTP, sender address, sending logs, and spam-filter checks. Do not look for the cause in Preview Submission if the entry is created correctly and the pre-submit preview works.

Limitations and Decisions Worth Making in Advance

The preview feature feels simple, but it has architectural limits. It should not turn into a user dashboard, a persistent draft system, or an editor for already submitted entries. The more clearly you understand the product's boundaries, the fewer unexpected requirements will surface after the form goes live.

Preview Is Not the Same as Entry Editing

After the entry is submitted, the user is no longer on the Preview Submission screen. If they need to come back a day later and change the request, you need a different mechanism. That might be entry editing through a dedicated tool, a user dashboard, a separate correction form, or manual processing by an administrator. Do not promise users "you can update your request later" unless that workflow is actually in place.

Preview Does Not Replace Validation

A review screen helps users catch human mistakes, but it does not replace required fields, email validation, phone-format validation, anti-spam protection, or server-side validation. If a field should be required, keep it required. If the email must be valid, rely on field validation. Preview is an additional user-side check, not protection against bad data.

Hidden Data Needs Separate Attention

If the form includes system hidden fields, UTM tags, internal identifiers, or technical values, decide in advance which of them can be shown. Sometimes UTM tags are useful for the manager but irrelevant to the user. Sometimes a hidden field contains a selected source or an internal code that should never be exposed. In those cases, a manual summary is safer than a full {all_fields} table.

Long Forms Need Clear Navigation

If the user notices an error on the last page, they need a quick way to understand how to fix it. For a short form, Previous is enough. For a long application, it is better to add clear page names, a progress indicator, and if needed, Multi-Page Navigation. Without that, the review screen can become an annoying obstacle: the error is visible, but it is not clear where to go back.

When Gravity Forms Preview Submission Is the Right Choice

Gravity Forms Preview Submission is worth using when your form matters enough to give users one final chance to review their data. That is especially valuable for long applications, registrations, service orders, bookings, and intake forms. The product does not require a separate dashboard and does not change the core Gravity Forms workflow: you still work with standard pages, HTML fields, and merge tags, but you gain a useful final step before submission.

Before going live, run through a short checklist: the form is multi-page, the HTML field is on the last page, the summary shows only the necessary data, hidden fields are not exposed, the buttons are clear, the mobile layout has been tested, the entry and notifications match expectations, and any conflict with Soft Validation has either been eliminated or accepted intentionally. If all of that checks out, you can move on to the install file and download Gravity Forms Preview Submission to test it on your site.

The main standard is simple: after setup, the user should not just see a table, but clearly understand what they are submitting and how to correct a mistake. If the preview screen helps someone complete the form with more confidence, the plugin is doing its job. If you need post-submission entry editing, drafts, a user dashboard, or a public entries directory, use Preview Submission as one part of a broader architecture rather than a substitute for all of those features.