Gravity Forms Partial Entries - WordPress Plugin

How to Configure and Use Gravity Forms Partial Entries in Real-World Workflows

Gravity Forms Partial Entries is not meant to dress up a form or replace the normal submission flow. Its purpose is more specific: it saves some of the data a visitor has already entered into a Gravity Forms form even if they never make it to the submit button. In this guide, we will look at when that feature is genuinely useful, how to enable it for a specific form, which save rules make sense, where to review partial submissions, and how to keep your WordPress database from turning into a warehouse of useless fragments.

We will pay special attention to how saving actually works: the plugin can create or update a partial entry through WordPress Heartbeat, during page transitions in a multi-page form, after a validation error, and when Save and Continue is used. That sounds straightforward, but this is exactly where most false expectations come from. Some users expect every character to be saved instantly, others enable collection on every form they have, and still others trigger notifications on every update and end up with a flood of unnecessary emails.

This guide is written as a practical working reference for a site owner, marketer, developer, or WordPress administrator who already uses Gravity Forms and wants a clean way to capture abandoned forms. We will not cover license purchases or activation workarounds. The point of this guide is to enable an add-on you already have access to, verify the outcome, understand the limitations, and decide whether Gravity Forms Partial Entries is the right fit for your specific form.

What follows includes practical configuration steps, a consultation request example, save verification, troubleshooting, cautious improvements through official hooks, and a comparison with nearby solutions. If you only want the short version, here it is: enable Partial Entries selectively, start with forms where an early email address or phone number has real value, and always test Heartbeat before rolling it out live.

What Problem Partial Entries Actually Solves

A standard WordPress form only treats a submission as real after it has been successfully submitted. While a visitor is filling out fields, the data lives in the browser and in the form's own processing flow. If the user gets distracted, closes the tab, gets stuck on a step, hits a validation error, or simply decides to come back later, the site owner usually sees nothing. That may be acceptable for a short contact form. But for a longer quote request, registration form, booking form, questionnaire, educational form, donation form, or pre-order form, losing unfinished input becomes a business problem.

Gravity Forms Partial Entries adds an intermediate layer between a started form and the final submission. The plugin saves entered values as a regular Gravity Forms entry with a partial status. An administrator can open the entry list, filter partial submissions, inspect completed fields, evaluate progress, and see where the user stopped. That is useful in two distinct ways: recovering a potential lead and diagnosing the form itself.

Lead recovery only works if the user left some way to contact them. If the partial entry contains a name, email address, phone number, or another permitted identifier, the sales or support team can carefully follow up. But if the form only saved a selected city, a rating, or a single checkbox, there is very little practical value. That is why good configuration does not start with the Enable button. It starts with a better question: which fields make a partial submission valuable enough to store?

Form diagnostics solve a different problem. Even without contact details, partial entries can show that users consistently reach the same step and then abandon the form. That might be a long document section, a required phone field that feels too aggressive, a difficult address validation step, a shipping cost issue, or a weak page in a multi-page form. In that sense, Partial Entries acts like a small drop-off log inside Gravity Forms. It will not tell you the psychological reason someone left, but it will show you where the completion flow stopped moving.

It is important not to expect more from the plugin than it actually provides. It is not a CRM, it does not guarantee that every character will be saved before a visitor leaves, it does not provide full resume functionality without additional Save and Continue configuration or Gravity Flow, it does not eliminate consent requirements for data processing, and it does not magically make a form user-friendly. Its strength lies elsewhere: it turns invisible form abandonment into a trackable record you can actually work with.

Where the Plugin Is Especially Useful

Partial entries work best on forms where the user invests real effort before final submission. That includes long questionnaires, multi-step forms, quote request forms, service-matching forms, course registrations, proposal requests, contact forms for expensive services, donation forms, requests with multiple option selections, and forms where a visitor may leave contact details first and then get stuck on the details later.

For these forms, every unfinished record answers a practical question: the user showed interest but did not make it to the end. If the first fields collect an email address or phone number, the partial entry may give your team a chance to politely ask whether the user needs help. If the first fields only classify the request, the entry can still be useful for analysis: you can see which step users most often struggle with and simplify the form accordingly.

On short forms with only two fields, the upside is more limited. If the user only has to enter a name and email and then click Submit, there is very little room between starting and finishing for meaningful recovery. The plugin may still save partial data, but the administrator will quickly get noise: empty or nearly empty partial entries, test attempts, spam actions, duplicates, and accidental clicks. On small forms, it is usually better to improve the wording, fields, and validation first, and only enable Partial Entries when you have a clear reason.

Who This Add-On May Not Be Right For

You should not enable the plugin on forms that collect sensitive data unless you have a clear legal and operational reason to do so. Gravity Forms documentation specifically notes that credit card data is not stored in partial entries, and files are not saved in Partial Entries until the form is fully submitted. But even if the plugin does not technically store the most sensitive fields, the rest of the values may still be personal data: name, email, phone number, address, comments, service selections, and even medical or legal context.

If your team is not prepared to review entries regularly, delete unnecessary records, handle data deletion requests, and explain to users that input may be stored before submission, it is better not to enable partial entry collection. Partial Entries adds responsibility. Your site will now store not only confirmed submissions but also unfinished traces of user behavior. That is manageable in a mature process, but it is a poor fit for a site where no one reviews the database and no one understands what is being stored.

The plugin can also be unnecessary if your primary goal is to let the user continue the form later. Gravity Forms already has Save and Continue for that, and there are separate tools for stronger autosave and draft management. Partial Entries can work alongside those mechanisms, but on its own it is mainly about giving the administrator visibility into unfinished entries. Do not confuse storage for the site owner with a smooth resume experience for the visitor.

What to Check Before Installing It on a Live Site

Before installation, it helps to do a quick audit of the form and the environment. This is not just a formality. Partial Entries depends on Gravity Forms, WordPress, the Heartbeat API, hosting behavior, the form structure, and how your team plans to use the saved data. If you skip the prep work, the add-on may technically turn on without delivering anything useful.

The first requirement is an installed and up-to-date version of Gravity Forms. The official system requirements documentation lists baseline requirements for Gravity Forms Core and also makes clear that official add-ons depend on the core version. The Partial Entries changelog notes a minimum Gravity Forms version of 2.7.0. You do not need to chase every latest build in an article like this, but before enabling the add-on on a production site, you should confirm that Gravity Forms, WordPress, PHP, and the database are all in a supported state.

The second requirement is access to the add-on itself. On the current product page, Gravity Forms lists Partial Entries as available on Elite and Nonprofit licenses. You may still see references to the legacy Developer license in older articles, but for decisions, it is better to rely on the current product page and your Gravity Forms account. If the add-on does not appear under Forms > Add-Ons, the issue may not be the site at all. It may simply be unavailable under your subscription.

The third requirement is knowing exactly which forms you are enabling. An official introductory Gravity Forms post explicitly warned power users to be selective and not enable Partial Entries on every form. The reason is practical: partial entries are stored as entries and can increase MySQL load. On a site with high traffic, active ads, multi-step forms, and a large number of fields, that is not a small detail. Use the plugin where each saved record has real value.

Quick Checklist Before You Turn It On

• Confirm that the form already works without Partial Entries: submissions go through, notifications are sent, required fields validate correctly, and the entry appears under Forms > Entries.
• Identify the earliest fields that make a partial entry useful: email, phone number, name, service type, order number, selected plan, or another permitted identifier.
• Check whether the form includes sensitive fields. If it does, decide whether unfinished input should be stored at all and how that should be explained to the user.
• Make sure the form does not begin with unnecessary fields. If the user first sees a long set of optional questions, Partial Entries will save a lot of weak records.
• Verify that your hosting or optimization plugins are not disabling WordPress Heartbeat on the public-facing side of the site. If Heartbeat does not fire, saves will mostly happen only on page transitions, validation errors, and Save and Continue.
• Decide who will review partial entries and how quickly. Collecting them without a follow-up process almost always turns into an archive instead of a useful tool.

Safe starting strategy: enable the add-on on one high-value form first, use a save rule based on the email field or a meaningful completion threshold, test it in a normal browser, and only then apply the same approach to other forms.

Privacy and the Warning Text

The plugin settings include a warning message displayed below the form description. It should explain that field values may be saved before the final submission. Do not hide this text or word it in a way that makes the meaning unclear. If the form collects personal data, align the wording with your data processing policy and internal legal process.

In practical terms, that means two things. First, the warning text should be short and human. Second, it should not promise something the site does not actually do. For example, you cannot say that data is only used after submission if Partial Entries is enabled and saves input earlier. A softer and more accurate version would be: data entered into the form may be saved in order to process your request and help complete the submission.

Installing the Add-On and Enabling It for the First Time

Gravity Forms Partial Entries is installed as an official Gravity Forms add-on. The standard admin path is to open Forms > Add-Ons, find Partial Entries, click Install, and then Activate Plugin. If you are installing from a ZIP file, it comes from your Gravity Forms account and is uploaded through Plugins > Add New > Upload Plugin. Composer is available for development environments, but most editors do not need it. It is mainly for teams that manage WordPress as a dependency-based project.

After activation, do not go looking for one global switch for all forms. The main setting lives at the individual form level. Open the form in the Gravity Forms editor, go to Settings > Partial Entries, and turn on Enable. That approach makes sense: a contact form, order form, partner application, and registration form may each need different save rules, different warning text, and different handling for partial entries.

Your initial check should start with the simplest configuration possible. Enable the add-on on a test form or a copy of a live form, add a clear warning message, avoid making conditional logic more complex than necessary, and run several scenarios: start the form and wait, move to the next page in a multi-page form, trigger a validation error, and click Save and Continue if that feature is enabled. Then open Forms > Entries, select the form, and check the Partial filter.

If you do not see a partial entry immediately after the first field is filled out, that does not automatically mean something is broken. The documentation explains that Heartbeat-based saving depends on how often the site sends heartbeat requests, usually at roughly 30 to 60 second intervals. If a visitor enters a value and closes the tab before the next heartbeat request, no entry may be created. In multi-page forms, a page transition often provides a more reliable checkpoint because saving also occurs during page transitions.

How to Run Your First Test Without Fooling Yourself

1. Open the page with the form as a normal visitor, ideally in a separate browser or private window.
2. Enter values into the first few fields, including the field that should make the record valuable for follow-up.
3. Wait longer than one Heartbeat interval without submitting the form. Do not close the tab immediately.
4. If the form is multi-page, go to the next step and then back again to verify saving during page transitions.
5. Open Forms > Entries, select the form, and check the Partial filter, progress, and saved values.
6. Fully submit the form and confirm that the final entry still works correctly with Partial Entries enabled.

You need this verification before you set up notifications or integrations. If a basic partial entry is not being created, it is too early to connect CRM, Zapier, Webhooks, or Gravity Flow. First, confirm that the plugin can create and update an entry in your specific environment.

How Saving Works: Heartbeat, Page Transitions, and Partial Status

The signature behavior of Gravity Forms Partial Entries revolves around save events. The user enters values into the form, the plugin gets an opportunity to save or update a partial entry, and then the record appears in the Gravity Forms database and in the entries list. This is not a separate analytics table and not a temporary cookie log. Gravity Forms documentation makes it clear that partial entries are entries. That means the record lives in a familiar Gravity Forms context: you can open it, inspect field values, use status filters, and work with it through compatible mechanisms.

The most widely known trigger is the WordPress Heartbeat API. This is WordPress's built-in mechanism for periodic AJAX requests that lets a page exchange data with the server without a full reload. In the Partial Entries context, it is used to send the current form values to the server from time to time. The documentation mentions an approximate 30 to 60 second interval, but actual behavior depends on the site, hosting, optimization plugins, and any restrictions around admin-ajax.

The second save path comes from the form's own actions. If the user moves to the next page of a multi-page form, goes back, clicks submit and hits a validation error, or uses Save and Continue, Partial Entries gets a more explicit opportunity to save. That is why long multi-page forms are usually a better fit than a short single-page form where a visitor can type into a field and leave before Heartbeat has a chance to fire.

The third layer is the logic that determines whether a partial entry should exist at all. The plugin does not have to create a record from the very first character if save conditions are enabled. In the settings, there is Enable Conditional Logic and a Progress section where you can choose criteria based on all fields or only required fields. For example, you can save the entry only after the email field has been completed or after a certain percentage of required fields has been filled out. That keeps noise down and makes the entry list usable.

Why an Entry Sometimes Appears Later Than Expected

A common mistake is to assume that Partial Entries works like per-keystroke autosave. The plugin saves data into real entries, but it does not guarantee that every instant change will be recorded. If Heartbeat has not sent the data yet and the user closes the tab, the last portion of input may be lost. If your host or performance plugin limits Heartbeat on the front end, interval-based saving may fail entirely or behave inconsistently.

The practical takeaway is simple: build checkpoints into critical long forms. Break the form into logical pages, move important contact fields closer to the beginning, do not force the visitor through one long page before the first save event, and do not assume that invisible hosting optimizations will always leave Heartbeat untouched.

How to Interpret Partial Status in the Entry List

The Entry List documentation explains that some add-ons add their own status filters, and Partial Entries may add a Partial filter. In day-to-day work, that means you do not need to mix unfinished submissions with normal submitted entries. Open the entries for the relevant form, switch to the partial filter, and review not just the fields but also the progress. If the form is multi-page, progress helps you quickly see which section the user reached before they stopped.

That said, a partial entry is still an incomplete record. You should not run the same process on it that you would use for a fully submitted form if the entry is missing consent, required data, or final confirmation. In CRM, it is better to label it as incomplete. In analytics, treat it as a signal of interest or abandonment rather than a true conversion. In follow-up, use careful wording: the person did not submit the final request, they only started filling it out.

Save Rules: How to Avoid Collecting Junk Partial Entries

The main quality lever in Gravity Forms Partial Entries is the rule that determines when a record gets created. If saving is too broad, you will end up with many entries that have no contact details, no clear meaning, and no useful next action. If the rule is too strict, the plugin will miss potentially valuable cases. The right setup depends on the form's purpose.

Open Settings > Partial Entries inside the form. The core settings are Enable, the user warning, and Enable Conditional Logic. Under Progress, you can choose between All Fields and Required Fields. Each approach has its own strengths.

All Fields takes the full set of form fields into account. That works well when the form is made up of roughly equal fields and you want a broad sense of overall progress. But if half the fields are optional, decorative, or conditionally displayed, the percentage may become less meaningful. Required Fields is often closer to actual submission readiness. If the visitor has completed a meaningful share of the required fields, the record is usually more useful. Even so, hidden conditional fields and the form structure can affect how progress feels in practice, so this should be tested in a real user flow.

A Contact-Based Rule

For lead generation, it often makes sense to save a partial entry only after the user has entered an email address or phone number. The idea is not to collect contact information at any cost. It is to avoid storing thousands of anonymous fragments. With conditional logic, you can create a rule that saves the entry if the email field is not empty or the phone field has been completed. If the email field appears late in your form, consider moving it earlier if that can be done without making the experience worse. A partial submission without a contact method is rarely useful for sales.

This setup works especially well for consultation requests, quotes, service bookings, pre-orders, and B2B inquiry forms. The user leaves contact details first and then chooses parameters. If they do not finish, the team sees the partial entry and can ask whether the user needs help. A contact-based rule should always be paired with an honest warning on the form, otherwise the user will not expect unfinished input to be stored already.

A Progress-Based Rule

A completion-percentage rule is useful when contact details are not the only valuable part of the submission. In a questionnaire, for example, you may want to see records where the person has completed most of the required questions even if the contact field appears near the end. In a product-matching request, selected parameters, budget, and region may matter. In that case, saving after a certain percentage of required fields may produce a cleaner list than saving immediately after the first email address is entered.

But a percentage-based rule needs testing. Run a few sample passes through the form: fill out only the beginning, then half of it, then all required fields except the last one, then trigger a validation error. After that, check when the partial entry is created. If it appears too early, raise the threshold. If it appears too late, lower it or add a rule tied to a specific field.

A Rule for Multi-Page Forms

A multi-page form gives you natural checkpoints through page transitions. That means the form structure matters just as much as the plugin settings. The first page should collect the minimum data needed to make the record meaningful: contact details, request type, or a basic service selection. The second page can add more detail. The third can gather supporting documents or comments. If the user abandons the form after the first page, the partial entry should already be understandable.

A poor setup would be a first page with ten general questions and no contact fields, with the email address only appearing at the end. In that case, the plugin may save progress, but the team still cannot act on it. Another poor setup is an overly aggressive threshold that creates an entry before the user has provided anything meaningful. A successful Partial Entries configuration starts with the form architecture itself: collect the minimally useful fields first, then move on to the more complex details.

User Warning and Personal Data

Partial Entries works with unfinished input, so the warning message is not cosmetic. The add-on settings include a Warning Message field that appears below the form description. Official documentation describes it as a message that informs the user that field values may be saved before submission. You should adapt that message to your site and your form, especially if a partial submission may include personal data.

A good warning does three things well. It clearly explains that saving happens. It does not overwhelm the user with legal jargon. And it does not promise something the site cannot actually deliver. For a consultation request, for example, a reasonable version might say: the information you enter may be saved on the server before submission so we can process your request and help you complete the form. If the form involves more sensitive context, the wording should be stricter and aligned with your privacy policy.

Do not disable the warning just to protect conversion rates. If the site starts saving entered values before the user submits the form, the visitor should understand that before they start typing. Some projects may also need to update the privacy policy, retention terms, partial entry deletion process, and internal staff guidance. This is not legal advice, but the practical minimum is obvious: store only what you need, explain why, and delete what you do not need.

A Safe Custom Warning via Hook

If the built-in warning field is enough, use it. If you need to change the text centrally or inject one standard version across all forms, the official gform_partialentries_warning_message filter lets you modify the warning programmatically. This is a small, reversible customization based on official Gravity Forms documentation. Add it through the Code Snippets plugin or a small custom functions plugin, not in WordPress core and not in Gravity Forms files.

<?php
add_filter( 'gform_partialentries_warning_message', function( $warning_message ) {
    return 'Data entered into this form may be saved before submission so we can process your request and help you complete the form.';
} );

Verification is straightforward: open the form as a visitor, confirm that the text appears below the description, start filling out the form, and then check the partial entry in the admin panel. Rolling it back is just as easy: disable the snippet or remove the filter. If different forms need different wording, use the form-ID-specific hook variant documented by Gravity Forms, but first make sure your team understands which forms require special language.

Do not edit plugin files. Any change inside the Gravity Forms or Partial Entries directories will be lost on update and may break support. Use form settings, Code Snippets, a child theme only for small safe inserts, or your own mini-plugin.

What Data You Should Not Collect Through Partial Entries

The official introductory Gravity Forms article notes that credit card data is not stored as a partial entry, and File Upload data is not stored until the form is fully submitted. That is an important limitation, but it does not mean you should blindly save everything else. If the form requests passport details, medical information, legal circumstances, data about minors, confidential financial details, or attachments, evaluate whether Partial Entries is appropriate before turning it on. In some cases, it is better not to enable partial saving than to explain later why unfinished input ended up in the database.

Even on standard lead forms, it helps to keep the beginning lean. Do not place sensitive fields ahead of contact details and consent. Do not save internal ratings or hidden calculations if they could be misinterpreted by staff. Do not automatically send partial entries to third-party services until you decide which fields should actually leave the site. If you do use integrations, run them through a separate process with a clear status marker so the partial entry does not look like a completed submission.

Save and Continue, Resume Links, and Partial Entries: Where the Boundary Is

Partial Entries and Save and Continue are often confused because both involve unfinished forms. But they solve different problems. Save and Continue gives the user a link so they can come back to the form later. Partial Entries gives the administrator visibility into unfinished input inside the entries list. Gravity Forms documentation for Save and Continue explains that this mechanism creates a resume link and stores draft data separately, while Partial Entries, when enabled on the same form, can save the resume URL and token alongside the partial entry.

This difference matters because it sets expectations correctly. If the user simply starts a form and leaves, Partial Entries may preserve the entered values for the administrator, but it does not necessarily give the user a smooth way to return to the exact same place. If the user clicks Save and Continue, they receive a resume link, and when Partial Entries is enabled, that resume link may appear in the entry detail and as an additional column. But the official documentation warns against editing partial entries when Save and Continue is used at the same time: partial entries and draft submissions are not synchronized, so changes to the partial entry can be lost when the user resumes the draft.

In other words, Partial Entries is about visibility and recovery for the team, while Save and Continue is about letting the user return to a draft. On complex forms, they can complement each other, but they should not be mixed without clear rules. If a manager manually edits a partial entry and the user later resumes the form through their draft link, those expectations can diverge. That is why teams should usually adopt a simple rule: a partial entry can be reviewed, labeled, and used for outreach, but not treated as the source of truth while the user still has a live draft they may complete.

When to Enable Both

The combination works well for long forms that users may realistically not finish in one sitting: course applications, funding requests, registrations with documents, multi-step service matching, or internal employee portals. Save and Continue lets the user keep a link and come back later. Partial Entries lets the team see that the form has been started and step in if needed.

The setup should be cautious. Enable Save and Continue in the form settings, edit its notifications and confirmations separately, then enable Partial Entries and verify that the resume URL appears where you expect it. Do not send repeated emails to the user on every partial entry update. And do not promise automatic resume functionality if it still depends on the user manually clicking Save and Continue or on a separate add-on.

When Partial Entries Alone Is Enough

If the form is short but the lead value is high, Partial Entries alone may be sufficient. For example, the visitor enters an email address, phone number, selects a service, and then is expected to add details. If they leave, a manager can contact them and clarify the request. The user does not necessarily need to resume the form themselves. In that situation, Save and Continue only adds interface complexity and another element that few people will use.

Partial Entries alone also makes sense when your goal is form-drop-off analysis. If you want to understand which step users abandon but do not plan to offer draft resumption, there is no need to enable Save and Continue. A partial filter, visible progress, a good test process, and regular entry reviews are enough.

When You Need a Different Autosave Tool

If your main requirement is automatic draft saving and automatic restoration for the user when they return to the page, Partial Entries may not be the center of the solution. Gravity Forms and Gravity Wiz document Save and Continue and Advanced Save and Continue separately because they solve the form-resumption problem directly. Those options are worth considering when user experience matters more than maintaining an internal list of partial entries.

A practical rule of thumb is this: if you need visibility into abandoned submissions, start with Partial Entries. If the user needs to continue a form without losing progress, look at Save and Continue and dedicated extensions. If you need email sequences that wait for final submission, look at Gravity Flow and its partial entry submission steps.

Notifications, CRM, and Gravity Flow Without an Email Avalanche

Once Partial Entries is enabled, the next idea is almost always to notify a manager or push the partial entry into a CRM automatically. That is possible, but it requires discipline. The official documentation for notification events shows that Partial Entries supports Saved and Updated events. Saved fires when a partial entry is first created, while Updated fires when an existing partial entry receives an update request. The documentation also warns that update requests may happen many times, including through Heartbeat even when no new field values have changed, so Updated can easily generate a large number of emails.

In a normal business workflow, sending an email on every update is almost always excessive. A manager should not get a notification every 30 to 60 seconds while a visitor is still thinking through the form. A better approach is one of these three: notify only on the first save, review the partial filter manually on a schedule, or use a workflow that waits to see whether the submission is truly abandoned.

Gravity Flow provides a more mature option. Gravity Forms documentation for abandoned form notifications explains that Partial Entries integrates with Gravity Flow and can start workflows when a partial entry is created. A workflow setting appears in Partial Entries, and Gravity Flow offers a Partial Entry Submission step that waits for the final form submission. This is useful when you need more than a manager notification. You may want a sequence that waits, checks status, sends a reminder, assigns a task, and then stops automatically after the form is fully submitted.

How Not to Mistake a Partial Entry for a Real Conversion

If a partial entry is sent into CRM automatically, mark it with a separate status. In official Gravity Forms hook examples, partial entries are explicitly labeled as partial before some feeds are processed. That matters for more than just technical reasons. The sales team needs to see that the person did not actually finish the submission. Otherwise, partial entries enter the pipeline as normal leads, your reporting gets distorted, and users receive messages written as if they had already completed the request.

In CRM, it is better to create a separate stage such as started form, incomplete submission, or soft follow-up required. A manager email can include the filled fields, progress, and a link to the entry detail, but it does not need every technical field. If the form entry contains sensitive context, verify whether that information can be sent to a third-party service at all. In some cases, it is safer to keep partial entries inside WordPress and handle them manually.

When to Use Saved and When to Use Updated

Saved works well as the initial signal that a new partial entry exists. It creates much less noise and is a good fit when the form uses strict save rules. For example, if the partial entry is only created after the email field is completed, the first save event is already meaningful. Even then, it is still wise to verify that spam or test values will not create unnecessary volume.

Updated is only useful when the logic around it is carefully thought through. It may fire many times while the user remains on the page. If you use Updated for an integration, add filtering in your CRM or workflow: only send the record after sufficient progress, avoid duplicate handling for the same partial entry, and do not email the user while they are still actively filling out the form. For many sites, Updated is best left without email notifications and used only in specialized code or workflow logic.

A Safe Integration Through an Official Hook

The official documentation describes the gform_partialentries_post_EVENT hook, which lets you perform an action after a partial entry is saved or updated. It also includes examples for Mailchimp, Webhooks, Zapier, and HubSpot through GFAPI::maybe_process_feeds. A general guide does not need to duplicate large integration code blocks when there is no specific service in scope. What matters more is the principle: you can process a partial entry as a separate event, but you should explicitly label its status and avoid running the exact same workflows you use for a final submission.

If a developer needs the integration, start not with code, but with the data flow: which event will be used, which fields are required, where the record will go, how duplicates will be excluded, and when the process should stop after the final submission. Only then should you use the official hooks. Do not send partial entries to third-party services by default. First, confirm that the user has been informed, that the data may legally be transferred, and that your CRM can distinguish an unfinished record from a normal submission.

Practical Example: A Consultation Form That Saves a Useful Lead

Let us walk through a realistic scenario. An agency website has a consultation request form. It has three pages: contact details, request type, and project details. Previously, the team only saw fully submitted requests. After a marketing campaign, it became clear that people were starting the form but not always finishing it. The goal of the implementation is to save the contact details and a basic classification of the request, identify the drop-off point, and avoid collecting empty partial entries.

Goal

You want a partial entry only when the visitor has already left an email address or phone number and selected a service type. If they simply opened the form and clicked the first checkbox, the record is not useful. But if they left contact details and dropped off on the project-details step, the manager should see an entry with partial status, understand which fields were completed, and decide whether follow-up makes sense.

Form Preparation

On the first page of the form, place a short group of fields: name, email, phone number, service type, and consent to data processing if your policy requires it. Do not overload the first step with long text. On the second page, ask about the project goal, timeline, and budget. On the third page, leave room for comments, extra parameters, and final submission. That structure makes the partial entry useful as early as the first step.

Before enabling the add-on, submit the form normally from start to finish. Check the standard entry, notifications, required fields, and confirmation. Then activate Partial Entries and configure the warning message. At this stage, do not add CRM integration yet. First, confirm that the partial entry is being created and that it contains exactly the fields you expect.

Partial Entries Configuration

1. Open the form in the WordPress admin panel.
2. Go to Settings > Partial Entries.
3. Turn on Enable.
4. Add an honest warning that entered data may be saved before the form is submitted.
5. Enable Enable Conditional Logic.
6. Create a rule that saves the entry if the email field is completed or the phone field is completed, and the service type has been selected.
7. If the form is long, also review Progress based on Required Fields, but do not replace the contact-based rule with it unless you have a clear reason.
8. Save the settings and clear test partial entries after verification.

This gives you a good balance. The plugin does not save every accidental touch of the form, but it starts working once the record has real practical value. If your niche tends to collect email addresses late in the flow, rethink the first page of the form. Partial Entries should support a good form architecture, not compensate for a weak one.

Verifying the Outcome

Open the form as a visitor, fill in the email address, phone number, and service type, move to the second page, and then either close the tab or stop without submitting. Wait long enough for Heartbeat if you are testing a single-page version. In the admin panel, open Forms > Entries, select the form, and enable the Partial filter. The entry should show the completed fields, and the progress should reflect the point where you stopped.

After that, submit another test entry all the way through. Make sure the regular submitted entry is still created, that the final-submission notification is sent, and that the partial entry does not interfere with validation. If you use Save and Continue, also test the resume link: click Save and Continue, open the entry detail, and verify that the resume link appears where you expect it.

Scenario summary: successful configuration is not defined by checking a box. It is defined by the quality of the saved records. Your partial entries list should contain contact details and understandable context, not random empty rows.

Follow-Up Nuances

An email or phone call triggered by a partial entry should sound different from a response to a completed submission. The person did not click the final button, so softer wording is better: you started filling out the form, and if you ran into a question, we would be happy to help you complete it. Do not say that the request has been accepted if it was never submitted. Do not attach the full set of entered data to the message unless that is necessary. And do not send an automatic reminder immediately after the first heartbeat, because the user may still be on the page.

For more advanced follow-up, it is better to use Gravity Flow or delayed CRM rules. For example, a workflow can wait for a period of time, check whether the entry became a completed submission, and only then send a reminder or create a task for the manager. That is far cleaner than sending an instant email on every partial entry update.

Analyzing Abandoned Forms: What to Look For in Entries

After a few days of use, partial entries become more than just a source of leads. They also become material for improving the form itself. Do not look at one entry in isolation. Look for repeated patterns. If users often complete the contact section and stop before the budget field, the field may be worded too aggressively. If they drop off on the file upload page, check the file size, format, required status, and explanatory text. If they get lost inside conditional logic, hidden fields may be making the form feel unpredictable.

It helps to configure the visible columns in the entries list. Gravity Forms documentation for Entry List explains column selection through the Select Columns window. For partial entries, it is useful to show the fields that help you quickly understand the record: email, phone number, request type, progress, date of last save, status, and if Save and Continue is enabled, the resume token or URL when relevant. Do not expose sensitive fields in the list if not every administrator needs to see them.

Regular analysis works best through simple slices: which forms produce the most partial entries, which step is most often the last one, which fields are completed before abandonment, how many partial entries later turn into completed submissions after follow-up, and which records are clearly spam. There is no need to build a complex analytics stack on day one. One responsible person and a short weekly review are enough to start.

How to Tell a Form Problem from Normal Behavior

Not every partial entry points to a problem. A user may simply have changed their mind, compared services, left the tab open, gotten distracted, or tested the site. It becomes a real issue when the same section of the form repeatedly causes people to stop. For example, most partial entries may show completed contact details and an empty budget field. Or many users may reach the file-upload page and leave. Or the share of partial entries may spike after you enable a new required field.

When that happens, do not blame the plugin. It is showing you the symptom. The fix usually lives in the form UX itself: shorten the field, add a hint, make the question optional, move a difficult field later, include an example answer, break a step apart, change the order, or remove an unnecessary condition. Partial Entries is useful not only because it preserves leads, but because it reveals where the form is weak.

How to Handle Partial Entries as a Team

If several administrators work on the site, agree on statuses and actions. Who opens partial entries? When is a record valuable enough for outreach? How do you mark a record that has already been handled? When do you delete empty or outdated entries? Who handles user data requests? Without those rules, the list quickly becomes hard to interpret.

For a small team, a simple workflow is enough. New partial entries are reviewed once a day. Records without contact details are deleted or kept only for aggregate analysis. Records with contact details and clear interest receive a soft follow-up. If the user later submits the form in full, the partial entry is not treated as a separate lead. If a record looks like spam, it is not sent to CRM.

Configure by Form Type, Not with One Rule for the Entire Site

The most common mistake with Gravity Forms Partial Entries is finding one successful setup and then copying it mechanically across every form. Different forms have different abandonment patterns, different high-value fields, and different acceptable follow-up methods. It is better to think in terms of form classes, not plugin settings in the abstract. In one case, saving the email after the first step is enough. In another, the key issue is seeing which page of the questionnaire users abandon. In a third, the partial entry should only enter a workflow after the service choice and consent have been provided.

Below is a practical scenario map. It does not replace testing, but it helps you choose a starting configuration and avoid empty collection. For each case, think through the full chain: where the feature is enabled, what the user enters, which rule fires, what appears in entries, how to verify the outcome, what symptom indicates a failure, and where the limitations are.

Lead Form for a Consultation or Quote

For a lead form, the value of a partial entry almost always depends on the contact details. If the visitor leaves an email address or phone number and selects the inquiry topic, the record may already be useful. If they only open the form and type two words into a comment field, the value is much lower. So the starting setup is straightforward: Enable is on, the warning is adapted to your request-handling process, and Enable Conditional Logic is tied to the contact field and the request type.

User input: name, email or phone, requested service, and a short comment. Product behavior: the partial entry is created only after the condition is met. Visible outcome: in Forms > Entries, an entry appears with Partial status, and the list shows the contact and service. Verification: fill out the form up to but not including the contact field, then close the page. No entry should appear. Fill out the contact and service fields, then wait for Heartbeat or move forward in the form. The entry should appear. Failure symptom: entries are saved without contact details, or no entries are created after a valid email is entered. Fix: review the conditional logic, field order, and the exact field referenced by the rule. Limitation: follow-up should remain gentle because the user did not fully submit the request.

A practical detail here is that the email field should not be hidden on the final step. If the user must get all the way through a long flow before leaving contact details, Partial Entries can show interest without giving your team a way to respond. It is usually better to ask for the email earlier and explain why, for example so a manager can clarify details or send a quote. The phone field can remain optional if your audience prefers email.

Multi-Page Application or Questionnaire

For an application form, value does not always depend on contact information alone. Often what matters most is understanding where people stop: applicant details, documents, program selection, terms acceptance, or a long text answer. A multi-page structure helps here because page transitions become save checkpoints. The configuration can be tied to required fields or to progress percentage, but if contact details exist, it is still wise to collect them earlier.

User input: basic information on the first page, then more detailed sections. Product behavior: the partial entry updates on page transitions and through Heartbeat when available. Visible outcome: the administrator sees progress and the latest completed fields. Verification: complete the first step, move to the second, stop, and then check the partial entry. After that, continue to the third step, trigger a validation error, and check again whether the entry updates. Failure symptom: the record stays at old progress or does not reflect values from the new page. Fix: check for JavaScript errors, hidden conditional fields, and whether Gravity Forms and Partial Entries are up to date. Limitation: if the form contains sensitive information, you need a strict retention period and a clear warning.

For this kind of form, it is useful to create an internal report showing how many partial entries stop on each page. Even without advanced analytics, the entries list can show you which page needs redesign. If users consistently drop off right before document upload, add the allowed file list earlier, show size and format requirements, and offer an alternate submission method. If drop-offs rise on a long free-text answer page, add an example or break the question into smaller parts.

User Registration Form

A registration form is more complex than a standard lead form because the User Registration Add-On may be involved, along with username and email logic, user activation, and notifications. The Partial Entries changelog includes fixes related to preserving username and email fields when User Registration is used. That does not mean the combination is a bad idea. It means it should be tested especially carefully, and the add-ons should be kept current.

User input: email, username, name, password, and additional profile fields. Product behavior: the partial entry may save an unfinished registration as an entry with partial status, but it should not be treated as a created user account. Visible outcome: a partial entry appears in the entries list, while no full user account appears in WordPress users until the normal User Registration process completes. Verification: start registration and abandon the form, then check the entries list and the users list. After a full submission, confirm that the user is created only through the normal process. Failure symptom: staff assume a partial registration is a real account, or the CRM receives unfinished data as if the registration were complete. Fix: use a separate status, separate notifications, and check the add-on feeds. Limitation: password and other sensitive fields require special care, and the workflow must respect the incomplete state.

If your main goal is to let the user continue registration later, consider Save and Continue or a more specialized autosave tool. If your goal is to understand why users abandon registration, Partial Entries is the better fit. In either case, do not send a welcome email based on a partial entry before the registration is actually completed.

Order, Donation, or Prepayment Form Without Stored Payment Data

For payment-related forms, Partial Entries is only useful for the non-payment portion: contact details, selected option, comments, donation amount, or address if it is appropriate to store. Credit card field data is not stored as a partial entry. So do not expect a partial entry to recover the entire checkout experience. It can show interest and context, but it does not replace the payment transaction itself.

User input: contact details, selected product or amount, comments, then payment fields. Product behavior: the partial entry saves the permitted non-payment fields, while the payment add-on only processes payment after a completed submission. Visible outcome: the partial record in entries shows that the person started an order or donation, but the payment status should never be interpreted as a successful payment. Verification: start the order, fill in the contact and selection fields, leave before payment, and check the partial entry. Then run a safe test submission through the payment add-on's test mode. Failure symptom: the team treats a partial order as paid or sends an order confirmation before payment. Fix: use a separate status, a separate pipeline, and a hard rule against automatic fulfillment for partial entries. Limitation: payment and file fields are not part of a fully recoverable partial entry.

Follow-up in this scenario should be especially careful. Do not say that the order has been placed. Say that the person started the form and can reach out with questions or continue the checkout. If you use discounts or reminders, it is better to handle them through a delayed workflow so you do not interfere while the user is still actively filling out the form.

Survey or Feedback Form

For surveys, partial entries may be useful not as leads but as signals that a question is difficult. If respondents keep abandoning the form after the same block, the issue may be the wording, the length, the rating scale, or the fact that the question is required. But this is also the form type most likely to produce weak entries. Someone may click one star, change their mind, and leave. That is why the save rule should usually be tied to progress or to multiple important questions rather than to the first click.

User input: several answers, a rating, and a comment. Product behavior: the partial entry is created only after meaningful progress. Visible outcome: the administrator can see unfinished responses and the page where the user stopped. Verification: answer one question only, and no entry should appear. Complete a meaningful part of the form, and the entry should appear. Failure symptom: the entries list fills up with one-answer partials. Fix: raise the Progress threshold or change the required fields. Limitation: if the survey is anonymous, do not try to turn partial entries into personal follow-up without a legitimate reason.

How to Handle Partial Entries in the Admin Panel

After the technical setup comes the less visible but more important part: operations. Partial Entries creates records, not a ready-made sales system. If no one reviews entries, filters them, or deletes them, the plugin provides little value. That is why a working form needs a process: who reviews partial entries, what counts as a useful record, how fast to respond, what to do with duplicates, when to delete data, and which fields must not be passed further along.

In a small team, this process can be a short internal document. In a larger one, it may become part of a CRM or support workflow. But the principle is the same: a partial entry should not remain in an undefined state. It should either trigger a soft follow-up, be used as an analytical signal, or be deleted as outdated or useless.

Minimum Roles and Permissions

Not every WordPress editor needs access to unfinished submissions. If the form includes personal data, access to entries should be limited to the roles that genuinely need to work with incoming requests. Gravity Forms has its own access controls, and WordPress has roles and capabilities. Review who can open Forms > Entries, inspect entry details, export records, and delete them.

On a service website, three process roles are often enough. The site administrator configures the form and the add-on. The manager reviews useful partial entries and records the follow-up outcome. The privacy owner or business owner defines the retention period and deletion rules. When all three roles are blended together, errors become more likely: the manager changes settings, the developer does not know which records may be deleted, and the owner does not realize data is already being saved before submission.

Entry List Columns for Faster Work

The entries list becomes much more useful if you show the right columns. For partial entries, you usually do not need every field. You need a short decision panel: contact details, request type, progress, last save date, status, and if Save and Continue is enabled, information about the resume link. The Entry List documentation explains how to select columns through the Select Columns window. Use that so the manager does not have to open every entry blindly.

At the same time, do not expose sensitive fields in the shared list unless they are necessary for the first-level decision. In a consultation form, for example, it may be enough to show the email address and service. In an application, the step and status may be enough without showing every answer. This reduces unnecessary exposure and makes the review process faster.

Follow-Up Rules

Good follow-up starts by respecting the status of the record. The user did not submit the form, so the message should feel helpful, not like a confirmation of a completed request. A good approach is something like: you started filling out the form, and if you ran into a question or want to continue, we can help. A poor approach is: your request has been received, expect a call, even though the user never clicked Submit.

The timing depends on the form. For a consultation request, contacting the user within the same business day may be reasonable. For a more complex application, waiting may be better, because the user may have saved a draft or may return on their own. For a donation or order form, do not send an email instantly on the first save if the user may still be on the page. Gravity Flow or delayed CRM rules can help you avoid stepping in too early.

Within the team, it helps to record outcomes such as contacted, no response, completed form later, declined, deleted, or spam. If your process has no internal status for this, at least keep a small external log. Otherwise, one manager may contact the same person again after another manager already handled the case.

Cleanup and Retention

Partial entries should not live forever simply because they exist in the database. Define a retention period for unfinished submissions based on your policy and the type of data involved. Empty test records should be deleted immediately. Records without contact details that are only useful for analysis can be stored for a limited time or summarized into a report. Records with contact details should be handled under your normal personal data rules.

Do not automatically delete all partial entries without understanding the workflow if they are involved in Gravity Flow or used together with Save and Continue. But do not leave them forever either. A good practice is regular review, cleanup of junk data, and checking that forms later completed by users do not remain in the team's queue as unfinished leads.

Step-by-Step Rollout Protocol for a Live Site

Even if the setup seems simple, a live rollout should be handled like a small release. The add-on affects several moving parts: JavaScript on the form page, heartbeat requests, the entries database, notifications, privacy text, permissions, and neighboring add-ons. The checklist below helps you avoid missing something important and then trying to diagnose it only after managers start complaining.

Step One: Create a Copy of the Form or a Test Page

If the form is already receiving real submissions, do not enable new logic without testing it first. Create a copy of the form or a temporary restricted page where you can reproduce the structure, fields, and conditional logic. Confirm that standard submission, notifications, and confirmations still work. Only then should you enable Partial Entries. This is especially important if the form uses payments, user registration, multiple pages, hidden fields, or third-party feeds.

Step Two: Define What Counts as a Useful Record

Before enabling the add-on, write one sentence: a partial entry is useful when it contains specific fields. For example: an email address or phone number plus the selected service. Or at least half of the required application fields plus a contact field. Or the first registration step plus consent. That sentence should become your conditional logic or Progress rule. If you cannot define usefulness clearly, you are not ready to turn the plugin on.

Step Three: Test Four Save Events

Test the Heartbeat path, the page-transition path, the validation-error path, and Save and Continue if it is enabled. Every test should have an expected outcome. Do not rely on one successful case. For example, if a record appears after a page transition, that does not prove Heartbeat works. If a record appears after Heartbeat, that does not prove Save and Continue correctly stores the resume URL. Different events validate different parts of the mechanism.

Step Four: Set Up Notifications Only After Entries Are Stable

Once the record appears reliably and contains the right fields, then you can think about notifications. Not before. First decide which event you need, usually Saved rather than Updated. Then add a condition such as having a contact field or reaching sufficient progress. After that, verify that the final form submission does not send extra user emails and that the partial notification does not read like a submission confirmation.

Step Five: Launch, Watch, and Tighten the Rules

After publishing, do not assume the setup is final in the first few days. Review the records that come in. If there are too many empty ones, tighten the condition. If there are no records even though users are clearly abandoning the form, check Heartbeat and the Progress threshold. If managers receive too many signals, disable Updated and switch to manual review or a delayed workflow. If partial entries help recover leads, formalize the process and expand it carefully to similar forms.

A rollout can be considered complete when you can answer five questions: which form is enabled, what condition creates the record, where the record is visible, who handles it, and when it gets deleted or stops being actionable.

Compatibility, Load, and Limitations Worth Knowing Up Front

Partial Entries works inside the Gravity Forms and WordPress ecosystem, so its limits usually come from save events, entry storage, spam protection, form fields, and neighboring add-ons. A solid setup takes those boundaries into account before you roll it out on a high-traffic site.

Heartbeat and Hosting

The documentation states this directly: some hosting providers may disable Heartbeat, and in that case Partial Entry may not save on an interval. In a Gravity Forms support thread, a team member described a similar symptom: if Heartbeat does not fire before the user leaves and there is no page transition or validation error, the partial entry may never appear. That is not a bug in your use case. It is a limitation of the mechanism itself.

Test this on the live hosting environment, not only on a local site. If Heartbeat saving is unreliable, try a multi-page form structure, review optimization plugins, check security settings, inspect caching around admin-ajax, and review hosting restrictions. Do not blindly disable site protections. It is better to identify the exact cause: Heartbeat is blocked, requests are throttled, the form JavaScript is failing, the user leaves too quickly, or conditional logic does not allow saving.

Database Size and Entry Volume

An official introductory Gravity Forms post pointed out that partial entries are entries and can consume additional MySQL resources. This matters most on sites with ad traffic and long forms. If you enable the add-on on every form, the database will fill with records that no one ever reviews. That makes the admin overview worse, complicates reporting, and can increase load in the admin panel.

The practical approach is to enable Partial Entries only on forms with demonstrated value, define a save condition, delete junk records regularly, avoid showing unnecessary columns, and avoid sending every partial entry to external services. On larger sites, discuss retention in advance: how long unfinished submissions should be kept and who cleans them up. Gravity Forms gives you tools to review and delete entries, but the storage process is still your responsibility.

Fields That Are Not Saved or Need Extra Care

According to the official documentation, credit card data is not saved in partial entries, and File Upload is only stored after the form has been fully submitted. That makes sense, since payment and file fields require extra validation and protection. If your form depends heavily on those fields, the partial entry may look incomplete even after substantial progress. Do not assume that is a bug before checking the documentation for the specific field and add-on involved.

Fields hidden by conditional logic also deserve attention. The Partial Entries changelog includes fixes related to values in fields hidden by conditional logic. That is not a reason to avoid conditional logic. It is a reason to test real branches of the form. Walk through every path: service A, service B, user with a file, user without a file, invalid email, back navigation. That is the only way to understand which values should actually land in the partial entry.

Spam Protection and Submission Speed Check

The changelog includes several important updates: support for honeypot validation before a partial entry is created, an updated honeypot check that uses the Gravity Forms handler, support for aborting save when a field value is marked as spam through field context, and a fix for cases where the partial entry was not saved or updated during Heartbeat when Submission Speed Check was enabled in newer versions of Gravity Forms. The practical conclusion for administrators is clear: keep the add-on updated and test saving again after enabling anti-spam settings.

If you notice that partial entries suddenly stop appearing after changing spam protection settings, do not disable everything at once. First verify that normal form submission still works, then test the Heartbeat scenario, then a multi-page transition, then the conditional logic. If the issue is tied to a specific field or anti-spam rule, a developer may be able to use official hooks, but when possible, it is usually better to stay within the standard Gravity Forms settings.

Small Safe Enhancements for Developers

Most sites will not need code at all. Form settings, conditional logic, the warning message, the entries list, and a careful workflow cover the main use case. Code becomes useful when you have a clear reason that has already been validated: centralizing the warning text, preventing a partial entry from being saved under a specific condition, adding an internal note, or processing a partial entry after save. This guide does not include large universal snippets. Only small, reversible patterns based on official hooks.

Stop Saving for a Form with an Internal Flag

The official gform_partialentries_abort_save filter lets you stop the save or update of a partial entry under defined conditions. This is an advanced tool. It should not replace regular conditional logic if the condition can be expressed in the UI. But it is useful when saving must depend on a server-side check, an internal form mode, or another state that ordinary rules cannot express.

Below is a custom adaptation with a clear limitation: it demonstrates the principle for one specific form and one flag field, not a ready-made solution for every site. Before using it, the developer should replace the form ID and field ID with real values, test on a site copy, and confirm that partial entries are not needed when the flag is active.

<?php
add_filter( 'gform_partialentries_abort_save_12', function( $abort, $partial_entry, $partial_entry_id, $form ) {
    if ( $abort ) {
        return true;
    }

    $internal_mode_field_id = '7';
    $internal_mode_value = rgar( $partial_entry, $internal_mode_field_id );

    return $internal_mode_value === 'internal-test';
}, 10, 4 );

The basis here is the official gform_partialentries_abort_save filter, which was added to stop saving or updating a partial entry. Where to place it: a custom functions plugin or Code Snippets. How to verify it: go through the form with a normal value and confirm that a partial entry is created, then go through it again with the internal-test flag and confirm that no partial entry appears. Rollback is simple: disable the snippet. If you are not sure about the field ID, do not use the code on a live site.

Add Notes to Entries After Validation Errors

The official gform_partialentries_post_EVENT hook can run after a partial entry is saved or updated. The documentation includes an example that adds a note about validation errors to the entry detail. That can be useful for diagnosing multi-page forms: the team sees not only that the user stopped, but also which fields may have caused the validation error. That said, this kind of code already requires a working understanding of the Gravity Forms API and should be tested carefully.

For most sites, it is better to start without a snippet and review the fields directly. If the problem repeats, a developer can build on the official example and add notes only for one specific form. Do not turn every Heartbeat update into an entry note. The official example explicitly checks for AJAX Heartbeat requests to avoid creating unnecessary notes. That is a good rule for all Partial Entries extensions: write only meaningful events to the database, not every technical update.

How to Verify the Result After Configuration

Your test should simulate a real visitor, not just an administrator editing the form. An administrator may have different cookies, permissions, disabled cache, the WordPress toolbar, and different script behavior. That is why it is better to test in a separate browser, without logging into the admin area, on the published page containing the form.

Start with the basic scenario. Fill in the fields that should create a partial entry according to your rules. Wait longer than one Heartbeat interval. Then open the entries list and check the partial filter. If the entry exists, inspect the fields: do the values match, is the progress correct, and are there any extra empty entries? Then submit another test entry fully and confirm that the final process still works exactly as it did before the plugin was enabled.

The second scenario is a multi-page form. Complete the first page, click to move to the next step, and do not submit the form. A partial entry should appear or the existing one should be updated. Then go back, change one field, move forward again, and check whether the saved value updated. If the progress or data does not match, review the conditional logic and hidden fields.

The third scenario is a validation error. Fill out the form so that one required field is invalid, for example an incorrectly formatted email address. Click submit or move to the next page. Gravity Forms should show a validation error, and Partial Entries may save or update the record depending on your settings. This is an important test because many real abandonments happen right after failed validation.

The fourth scenario is Save and Continue if it is enabled. Click the save link, receive the resume URL, open the entry in the admin panel, and verify that the resume-related information is present. Then resume the form from the link and submit it fully. After that, confirm that the team does not continue treating the old partial entry as a separate submission.

Post-Test Verification Table

What counts as a successful Partial Entries setup

Check	Expected Outcome	What to Do If It Fails
Enter meaningful fields and wait for Heartbeat	An entry appears with Partial status	Check Heartbeat, cache, JavaScript errors, and save rules
Move between form pages	The partial entry is created or updated	Check the multi-page structure and conditional logic
Trigger a field validation error	The entry keeps current values without breaking submission behavior	Check validation, anti-spam settings, and field conflicts
Final submission	A normal completed entry is created and notifications still work	Separate partial and submitted notifications, then review feeds
Review the entries list	The Partial filter is available and the right columns are visible	Configure Select Columns and user permissions

When You Should Not Enable Gravity Forms Partial Entries

There are situations where the plugin technically works but creates operational problems. The first is a form with a high volume of casual traffic and low value per contact. If visitors start the form out of curiosity and the team is not prepared to handle unfinished inquiries, partial entries become noise. You will see many records without any clear next action.

The second is a form with strict consent requirements. If the user must explicitly accept terms before anything meaningful should be stored, and you want to save fields before that point, the process needs especially careful review. A partial entry may be created before final consent if the rules are configured poorly. In that case, it may be better to move contact collection until after a clear warning and consent step, or not enable Partial Entries on that form at all.

The third is a form where the main value lies in uploaded files or payment fields. Since File Upload and Credit Card fields are not stored as ordinary partial entry data, the partial record may not give you what you actually need. For those forms, it is usually better to improve the steps, guidance, Save and Continue behavior, multi-file uploads with proper validation, or a separate support workflow.

The fourth is a site where Heartbeat is intentionally limited and the form is single-page. If there are no page transitions, no Save and Continue, and Heartbeat is being throttled by hosting or optimization settings, Partial Entries will behave unpredictably. In that case, adjust the form structure or the environment first, then enable the add-on.

The fifth is any project with no process owner. If no one is responsible for partial entries, they will accumulate. That is bad for privacy, bad for the database, and bad for team quality. Any lead-recovery tool requires a simple operational framework: who reviews records, what they do with them, when they delete them, and what gets passed downstream.

Troubleshooting: Why Partial Entries Are Missing or Look Wrong

Problems with Gravity Forms Partial Entries usually fall into a few broad groups: the record is not created, it appears too late, too many empty records are created, required fields are missing, notifications are noisy, or Save and Continue does not behave the way you expected. The best way to troubleshoot is from simple to complex: form, settings, save event, environment, neighboring add-ons, then code.

No Entry Is Created After a Field Is Filled Out

Symptom: the visitor enters values and leaves the page, but no entry with Partial status appears under Forms > Entries. A likely reason is that Heartbeat did not fire in time, was disabled, was blocked, or the conditional logic did not permit saving the entry.

First, test the form without conditions. Enable Partial Entries on a test copy, fill out several fields, and wait longer than one Heartbeat interval. If it is a multi-page form, move to the next step. If the entry appears on page transition but not after simply waiting, the Heartbeat path is probably the issue. Check the hosting setup, optimization plugins, admin-ajax blocking, and any JavaScript errors on the page.

The fix depends on the cause. If Heartbeat is intentionally limited, it is usually not worth damaging site performance to support one narrow scenario. Rebuild the form as a multi-page flow or add Save and Continue where users need to return later. If the issue is conditional logic, simplify the rule and verify which fields must actually be completed before saving is allowed.

Too Many Empty or Weak Records Are Being Saved

Symptom: the entries list contains many partial entries without an email address, phone number, or any meaningful context. The likely cause is that the plugin is enabled too broadly and no useful save condition has been configured. This is especially obvious on high-traffic forms or on pages where users frequently click into fields without intending to submit.

What to check: whether Enable Conditional Logic is on, where the contact fields appear in the form, which Progress threshold is selected, which fields are required, and whether the first step contains anything valuable. The fix is to save the partial entry only after a contact field, after a key service selection, or after a meaningful percentage of required fields. Sometimes the real fix is field order: move the email and request type higher, and push less important details lower.

Rolling back a questionable setup is easy: disable Partial Entries for the weak form or temporarily remove the rule that creates extra records. After changing the configuration, clear out old test entries so the team is not analyzing junk alongside new data.

Some Fields Did Not Make It Into the Partial Entry

Symptom: the entry exists, but it does not contain data the user clearly entered. First, separate expected limitations from actual failures. Gravity Forms officially states that Credit Card fields are not stored in partial entries, and File Upload fields are only stored after a full submission. So missing data in those fields does not necessarily indicate a bug.

If ordinary fields are missing, check the conditional logic, hidden sections, multi-page transitions, and the exact moment the save occurred. The user may have entered the value after the last Heartbeat and left before the next request. Also check whether the field is being populated programmatically by another hook. The gform_partialentries_pre_update documentation notes that the partial entry contains current values from the browser plus a limited set of properties, so programmatically assigned values may not persist into the update without additional handling.

The fix may be to add a checkpoint, move the important field earlier, review hidden conditions, update the add-on, or, if the problem is specifically tied to a programmatic field, use the official gform_partialentries_pre_update filter only after a developer has tested it.

Notifications Arrive Multiple Times

Symptom: a manager receives several emails for one unfinished form. The likely cause is that the notification is attached to the Updated event, which may fire on every update request, including Heartbeat. Gravity Forms documentation explicitly warns about this behavior.

What to check: the notification event, notification conditional logic, CRM integration, duplicate feeds, and Gravity Flow steps. The fix is to use Saved for the initial signal, add a progress-based condition, move reminders into Gravity Flow with a waiting step, or disable Updated-based emails entirely. The quickest rollback is to temporarily disable partial notifications and rely on manual entry review until the workflow is properly configured.

Save and Continue Does Not Match the Partial Entry

Symptom: an administrator edits a partial entry, but the user opens the resume link and sees different data, or the manual changes disappear. The cause is documented in Partial Entries: partial entries and Save and Continue draft submissions are not synchronized, so editing a partial entry while Save and Continue is active is not recommended.

The fix is to separate roles. Treat the partial entry as a signal, not as the user's editable draft. If data needs to be corrected, it is usually better to wait for final submission or build a separate workflow. If the user needs to continue the form, use Save and Continue and do not promise that manual edits to the partial entry will change the saved draft.

Partial Entries Interferes with Limits, Anti-Spam, or Other Add-Ons

Symptom: after enabling the plugin, entry limits, anti-spam, User Registration, Survey, or an integration behaves oddly. The Partial Entries changelog includes fixes related to honeypot behavior, Submission Speed Check, entry limits, User Registration username and email fields, and Survey fields. That tells you compatibility has evolved over time, and older installations may behave differently.

What to check: Gravity Forms and add-on versions, the changelog, enabled anti-spam settings, a stripped-down version of the form, and whether the conflict happens only on one form or everywhere. The fix is to update Gravity Forms and the add-ons, disable third-party conflicts on a test copy, and review the official documentation for the specific add-on involved. If the issue can still be reproduced on current versions without third-party conflicts, opening an official support ticket is usually the right next step.

How to Decide Whether the Plugin Is Worth Keeping After Testing

The decision to keep the plugin should be based not on whether it turned on successfully, but on the quality of the outcome. After a test period, look at four indicators. First, the share of useful partial entries. If most of them include contact details and clear intent, the configuration is working. If the entries are mostly empty, your rule is too broad or the form structure is weak.

Second, the team's response speed. Partial Entries only matters when someone actually uses the records: calls, writes, analyzes, and improves the form. If entries sit untouched for weeks, data collection becomes a liability rather than an advantage. Third, the impact on the database and admin panel. If entries grow quickly, filters become slow, and the team starts drowning in the list, you need stricter rules or you need to disable the plugin on lower-value forms.

Fourth, the quality of the follow-up itself. If the follow-up helps recover some inquiries and does not generate complaints, the process is useful. If users are surprised that you have their unfinished data, revisit the warning message, privacy policy, and the tone of your outreach. Good partial-entry follow-up helps people finish something they already started. It does not pressure them with the fact that their input was saved.

For the final decision, use a simple standard. Gravity Forms Partial Entries is worth keeping on a form if it delivers at least one of these outcomes: the team recovers valuable inquiries, you identify weak points in the form, or a Gravity Flow workflow helps users return and complete the process. If none of those outcomes appears, disable the plugin on that form and simplify the form itself.

Questions That Commonly Come Up with Partial Entries

Can I enable Gravity Forms Partial Entries on all forms at once?

Technically, the plugin is configured at the form level, and that is the right design. In practice, enabling it on every form is usually a bad idea. Official Gravity Forms materials recommend being selective because partial entries are stored as entries and increase the amount of data in the database. Start with forms where an unfinished submission has real value: long applications, lead forms, registrations, consultation requests, or multi-step inquiries.

Does the plugin save data instantly for every character the user types?

No. Saving depends on the Heartbeat API and on form events such as page transitions, validation errors, and Save and Continue. The documentation describes an approximate Heartbeat interval of 30 to 60 seconds, and support discussions confirm that if Heartbeat does not occur before the user leaves, the record may never be created. For critical forms, use multi-page checkpoints and test behavior on the live hosting environment.

Can a user continue the form from a partial entry?

Partial Entries primarily saves the unfinished record for the administrator. If the user needs to continue the form, you need Save and Continue or another dedicated solution. If Save and Continue is enabled together with Partial Entries, the resume URL and token may be stored with the partial entry, but partial entries and draft submissions are not synchronized. That is why you should not edit a partial entry as if it were the user's draft.

Which fields are not stored in partial entries?

Gravity Forms officially states that Credit Card field data is not stored, and File Upload field data is only stored after the form is fully submitted. This is done for security and file-validation reasons. If your form depends heavily on files or payments, a partial entry may still be useful for contact details and context, but not for full recovery of the submission.

Why do notifications arrive multiple times?

Most likely because the notification is tied to the Updated event. Gravity Forms documentation warns that a partial entry may receive many update requests, including Heartbeat requests even when no new data is entered. For most sites, it is better to use the Saved event, separate conditional logic, or Gravity Flow with a delay and final-submission check.

Do I need to warn visitors that their data may be saved?

Yes. Partial Entries includes a Warning Message setting that appears below the form description. You should adapt it to your site and your data-processing policy. If the form stores entered values before the final submission, the user should understand that before they begin typing. For sensitive data, also review legal requirements and your internal record-deletion process.

Will Partial Entries affect site performance?

The add-on saves records into entries and uses events such as Heartbeat, so the impact depends on traffic volume, the number of enabled forms, the save rules, the hosting environment, and the number of stored records. On one properly configured form, the load is usually easy to control. If you enable it on every form without rules on a high-traffic site, you may create unnecessary records and extra requests. That is why it is best to start with one form and measure the practical outcome.

What if I only need partial entries for CRM?

First, make sure the record contains a useful contact method and that the user has been informed that their data may be saved. Then mark these records as incomplete, do not send them into the same pipeline as normal submissions, and avoid triggering notifications on every Updated event. For more complex logic, use official hooks or Gravity Flow, but do not send every partial entry to an external service by default.

When Gravity Forms Partial Entries Is a Strong Choice

Gravity Forms Partial Entries is worth using if you already work with Gravity Forms and want to see unfinished submissions in the same place where you review normal entries. The add-on is especially useful for forms where the visitor leaves contact details early and then moves through a longer path: selecting a service, answering questions, entering project details, completing registration, or filling out an application. In those situations, a partial entry helps you avoid losing interest and also shows you where the form is creating friction.

A successful setup depends on four things: selective activation, an honest warning, a meaningful save rule, and proper testing. If you enable the plugin on every form, save too early, and assign no one to manage entries, its usefulness disappears quickly. But if you turn it on for the right form, save only entries with contact details or enough progress, and monitor common drop-off points, Partial Entries becomes a genuinely useful working tool.

Before rolling it out on a production site, test the form, Heartbeat behavior, page transitions, validation errors, Save and Continue, notifications, and the entries list. After a few days of use, review which records actually help the team. If everything lines up, you can download the latest version of Gravity Forms Partial Entries and carefully integrate it into the site's main workflow.

The main takeaway is simple: Partial Entries will not fix a bad form automatically, but it gives you data you did not have before. Use that data not to pressure users, but to help them, recover valuable inquiries, and improve the form itself. When you do that, Gravity Forms Partial Entries becomes a useful part of your submission system rather than just another enabled add-on with no owner and no purpose.