GravityKit GravityImport - WordPress Plugin

GravityKit GravityImport Guide: Importing CSV Entries into Gravity Forms Without Data Chaos

GravityKit GravityImport is not meant to dress up a form or handle ordinary styling tweaks. Its purpose is more practical: take a spreadsheet of inquiries, registrations, orders, applications, or other structured data and turn CSV rows into Gravity Forms entries. In this guide, we will walk through how to prepare the file, choose the right form, map columns to fields, enable the import options you actually need, verify the results, and understand where the plugin is helpful and where another tool may be a better fit.

This article is written for site owners, WordPress administrators, developers, and support specialists who need to move data into Gravity Forms without losing the meaning of each column. We are not going to rehash the product page or the developer's marketing claims. Instead, we will follow a real working scenario: from cleaning up a CSV file to reviewing entries in the admin panel, reading the error report, and resolving common problems.

The core principle is simple: entry imports are only safe when you already understand the form structure, the behavior of required fields, notifications, processing feeds, and the limitations of CSV. GravityImport makes the job much easier, but it does not remove your responsibility for the quality of the source spreadsheet. That is why each section covers not only what to click, but why it matters.

When Entry Import Solves a Real Problem

Gravity Forms is usually seen as a tool for collecting new submissions. But many websites already have data that existed before the form itself: a lead spreadsheet from an old CRM, an event attendee list, submissions from another plugin, an exported registration log, an archive of inquiries, old rows from Google Sheets, or an Excel export. Manually adding hundreds of rows in the admin panel takes hours and almost always leads to mistakes. GravityImport is designed to bridge exactly that gap between a spreadsheet and Gravity Forms' internal entry storage.

The plugin works through a guided import flow: you upload a CSV file, choose an existing form or create a new one, map the file columns to Gravity Forms fields, and then configure how the data should be processed. The official documentation shows that the process starts from the Import Entries screen under Forms - Import/Export, and after the file is uploaded the plugin lets you choose a form, map fields, configure options, and review the final status.

What Kind of Data GravityImport Handles Best

The plugin works best when the source data already looks like form entries: one row equals one submission, application, registration, request, lead, or participant. For example, if the spreadsheet has columns such as Name, Email, Phone, Message, and Status, they can be mapped to fields in an existing contact or registration form.

• Migrating old submissions into Gravity Forms so the team can view the full history in one interface.
• Creating a new form from CSV when the spreadsheet already defines the future fields and choice options.
• Bulk-adding participants, subscribers, applications, or requests into an existing form.
• Updating existing entries when the CSV includes an Entry ID column and you fully understand what replacing an entry means.
• Importing files attached to Gravity Forms submissions through the File Upload field when the source files are available for download.

GravityImport should not be treated as a universal migration tool for every form on every site. The developer's official responses specifically note that when you migrate from other form plugins, it may recover the basic structure from the data, but it does not bring over complex form logic as-is. Conditional logic, multi-page structures, calculations, and custom workflows need separate review or a different tool altogether.

Who This Plugin Fits - And Who It May Not

GravityKit GravityImport is a good fit for teams already using Gravity Forms and wanting to work with imported rows as regular entries. That point matters: after a successful import, the data appears in the form's entries section, where it can be reviewed, filtered, exported, displayed through related GravityKit tools, or processed further using compatible Gravity Forms workflows.

The plugin is a weaker choice if you want to import complex forms from another builder together with their conditions, pages, calculations, and custom integrations. It is also not intended for public CSV uploads by regular visitors: the official FAQ states that imports are run from the WordPress admin area and require administrative access. For user-submitted file uploads, it is better to design a separate form, manual moderation flow, or a custom process.

Practical takeaway: GravityImport works well when you have a spreadsheet of entries and a clear target form. If you need to migrate the full business logic of another form plugin, separate the data from the logic first and decide what should actually become Gravity Forms entries.

What to Check Before Uploading a CSV

Preparing a CSV may feel tedious, but it is what determines whether the import will be fast or turn into a long series of fixes. GravityImport can preview data, map columns, and validate rows, but it does not know which values are correct for your site. If the spreadsheet mixes date formats, leaves required fields empty, or uses unexpected dropdown values, problems will show up either during validation or after the import begins.

File Structure and Column Names

The first row of the CSV should make sense to a human reader. Column names help not just you, but the mapping process itself. GravityImport documentation specifically highlights the importance of naming your field columns, because headers like email_address, First Name, Event Date, and Message are much easier to match to form fields than vague labels like Column 1, data2, or old_field_17.

Before importing, open the file in a spreadsheet editor and check a few things:

• Each row represents one entry, not a mix of different entities.
• The first row contains headers that reflect the meaning of the data.
• Email addresses, phone numbers, dates, and numbers use a consistent format within each column.
• Columns with selectable options use values that either match the form options or can be safely added when creating a new form.
• There are no blank rows in the middle of the file, accidental totals rows, internal notes, or merged cells that CSV cannot preserve anyway.

Encoding, Delimiters, and Exporting from Excel or Google Sheets

The official upload-step documentation makes it clear that Entry Importer accepts CSV files. If your data currently lives in Excel, Google Sheets, LibreOffice, or Apple Numbers, it needs to be exported to CSV. That is not just a formality: with the wrong encoding, non-English names can turn into unreadable characters, and with an unexpected delimiter, all columns may collapse into a single line.

If you are working with multilingual data, build a small test file with 5 to 10 rows first. Include non-English characters, an email, a phone number, a date, a dropdown value, and one empty optional field. Upload it to GravityImport and make sure the preview displays everything correctly. If the characters break, go back to the export settings and choose UTF-8 CSV wherever your editor supports it.

Existing Form or New Form

GravityImport supports two distinct scenarios. The first is importing into an existing form. This is convenient when the form is already configured, has the fields you need, includes notifications and integrations, and the team already knows where to find the entries. The second is creating a new form from CSV. The official documentation explains that when you create a new form, the plugin can detect field types from the data and add choices for radio buttons, checkboxes, and dropdown options based on the CSV values.

Your choice affects the level of risk. Importing into an existing form is stricter: values need to match the form fields and validation rules. Creating a new form is more flexible, but it still requires follow-up work: field labels, required settings, notifications, confirmations, the public form layout, access permissions, and test submissions all remain your responsibility.

Installation and First Launch in WordPress

Installing the plugin should not turn into a project of its own. In a normal workflow, a WordPress administrator uploads the ZIP archive through Plugins - Add New - Upload Plugin, activates the plugin, and then goes to Gravity Forms. What matters here is not how the install button looks, but what you verify after activation.

Before your first import, make sure Gravity Forms is already installed and active. GravityImport is a tool for Gravity Forms entries, so without the base form plugin the whole workflow is pointless. Then review the user role. The developer hooks documentation shows that access to the importer's REST actions relies on capabilities such as gravityforms_edit_entries or gform_full_access, and creating new forms requires gravityforms_create_form. In practice, that means the import should be run by a user with proper permissions, not by a random site editor.

Where the Import Tool Lives

The official getting started guide shows the path in the WordPress left-hand menu: hover over Forms, open Import/Export, then choose Import Entries. That opens the GravityImport upload screen. If you do not see the menu item, first check that Gravity Forms is active, GravityImport is active, and the current user has the required permissions.

A Safe First Run

Do not start with a full file containing thousands of rows. Even if the plugin is built for large CSV imports, the first run should always be a test. Copy 5 to 20 rows from the source spreadsheet into a separate CSV file, include several data types, and add one deliberately problematic row. That kind of test shows how mapping, required fields, value selection, notifications, and the error report will behave.

1. Create a site backup, or at minimum a database backup, before any large import.
2. Open the target form and note the current number of entries.
3. Prepare a short CSV with typical rows and one row designed to trigger an error.
4. Run the import into a test or non-public form if that is possible.
5. Check whether the entries appear correctly, whether the fields display properly, and whether any unnecessary notifications were sent.

Do not enable notifications or feeds on the first trial import unless you are sure about the consequences. Otherwise every CSV row may trigger emails or external integrations, which is especially problematic when importing historical data.

The Import Map: From File to Gravity Forms Entry

To use GravityKit GravityImport well, it helps to think of the import as a chain of five stages: file, destination, mapping, processing options, result. A problem at any stage does not automatically mean the plugin is broken. More often, it means there is a mismatch between what is in the CSV and what the form expects.

Stage 1: Upload and Preview

At the upload stage, Entry Importer tries to detect data types and build a preview. This is not final validation, but the first filter. If the file cannot be read, the columns are not splitting correctly, or the headers look strange, fix the CSV before choosing a form. Do not keep going assuming the next step will somehow straighten things out.

Stage 2: Choose the Destination

After uploading, you choose where the rows should go: into an existing form or a new one. The form selection documentation notes that the list can be scrolled and searched by name, and if a form is missing it may be in the trash or inactive. This is a common small issue: the administrator remembers that the form exists, but the importer does not show it because the form is disabled.

Stage 3: Map the Columns

Mapping is the central step. For each CSV column, you choose a Gravity Forms field. If a column is not needed, you can skip importing it. If you are creating a new form, you can add a new field during the import. The important thing is not to map data automatically just because the names look similar. For example, a column called Created might mean the date the entry was created, the request date in an old system, or the date of an event. Those are different meanings, and the mistake may only show up later in reporting.

How to Map More Complex Fields

For simple fields like name, email, and plain text, it is usually enough to confirm the format. Lists, checkboxes, addresses, phone numbers, files, and pricing fields need extra attention. The official product page states support for core Gravity Forms field types and entry metadata, but that does not mean every arbitrary value from an old spreadsheet will automatically become a valid value for a specific field. If the form uses a strict list of allowed options, make sure the CSV values actually match those options.

Stage 4: Configure Options

After mapping, you arrive at the import settings screen. According to the documentation, this may include options for continuing after errors, ignoring required fields, processing feeds, conditional import, and email notifications. The exact set of visible settings depends on the form and the scenario. For example, Ignore Required Fields only appears when you import into a form that contains required fields.

Stage 5: Report and Entry Verification

After the import starts, you see a live status display and then a summary. If there are no errors, you will see a success message and a button to view the imported entries. If some rows are rejected, the summary should show the number of created entries, the number of errors, a link to the log, a button to view the created entries, and an option to return to mapping. This report is what you should read before rerunning anything, otherwise you risk repeating the same mistake.

Detailed Configuration After Installation

The settings area in GravityImport matters just as much as the CSV itself. This is where you decide whether the import should be strict, whether it should continue after a bad row, and whether it should trigger notifications or external processors. A mistake in these settings rarely breaks the site technically, but it can create incorrect entries, send unwanted emails, or launch integrations at the wrong time.

Continue Processing If Errors Occur

This option is useful when you want the entire CSV to be processed and then receive a report of problematic rows instead of having the import stop at the first error. The official documentation explains that when this is enabled, the import does not fail immediately - it goes through all rows and then shows an error report. That is convenient for large files where a few rows may be corrupted but most of the data is still valid.

For an initial test, it can be helpful to enable this if you want to expose every weak point in the spreadsheet at once. For the final import, you can also leave it on, but only if you are prepared to review the log and re-import the corrected rows afterward. If the data must enter the system in a strict all-or-nothing way, it is better to create a clean test file first and only then run the full import.

Ignore Required Fields

This setting appears when the target form contains required fields. It allows you to import rows where those fields are empty. At first glance, that can seem like a lifesaver for old spreadsheets, but it should be used carefully. A required field usually reflects a business rule: without an email address you cannot contact the person, without a date you cannot schedule an appointment, and without a category you cannot route the request properly.

Enable ignored required fields only when you have a clear downstream plan. For example, you may be importing an archive of inquiries where old entries should not re-enter an active workflow, but still need to be preserved for history. If imported entries will be used in reporting, automation, or public display, empty required fields can break the logic long after the import is complete.

Process Feeds

If the form has feeds configured through compatible add-ons, GravityImport can run the selected feeds for every imported entry. The documentation notes that feed conditions are respected as well. This is a powerful feature, but it also demands the most caution. A feed may send data to an external service, create a subscriber, update a CRM, or trigger a payment or marketing workflow if that integration is configured in the form.

A common safe rule: first import a small batch of test rows without enabling Process Feeds, verify the entries, and then decide which feeds, if any, should actually run for historical data. For archived submissions, it is often enough to create the entries without retriggering outside integrations. For a live lead migration, by contrast, sending the data onward to the CRM may be essential - but only after the conditions have been tested.

Conditional Import

Conditional Import allows you to import only the rows that match a condition instead of importing the entire file. This is useful when a single CSV contains several segments: only paid registrations, only active inquiries, only entries from a certain region, or only rows with a populated email address. Instead of manually filtering the spreadsheet first, you can apply the condition during the import.

But conditional import has a typical trap: people forget the filter is enabled and then wonder why fewer rows were imported than expected. So after the run, compare the number of rows in the CSV, the number of rows that should pass the condition, and the number of created entries shown in the summary. If those numbers do not line up, check the condition before you start blaming the field mapping.

Email Notifications

The email notifications option triggers Gravity Forms notifications for each CSV row. That is not always desirable. If you are migrating old inquiries, a mass email send to users may look like a mistake or spam. If you are importing fresh registrations and want an internal notification to reach a manager, the setting may be helpful.

Before enabling it, open the form settings and review which notifications exist, who receives them, and which merge tags they use. It is often better to create a separate internal notification for imports and disable user-facing emails if the imported data should not contact people again.

Skip Field Validation and Strict Values

The official product page and documentation both emphasize data validation. That is one of the reasons to use a guided import instead of writing directly to the database. If the CSV contains a bad date, an invalid email, or a number in a field that expects a different format, the plugin may stop or mark the row as an error. In some scenarios there is a Skip Field Validation setting, but it should not be used simply to push data through without understanding the consequences.

If the imported data will be used in calculations, filtering, search, exports, or integrations, it is better to fix the CSV than to disable validation. Skipping validation only makes sense for a controlled archival import where you knowingly accept incomplete legacy data and do not use it in active workflows.

Practical Scenario: Migrating Requests from an Old Spreadsheet

Let us look at a specific example. A website has an old spreadsheet of consultation requests: name, email, phone number, subject, message, request date, and processing status. The team now uses Gravity Forms, but the historical inquiries still live separately in Google Sheets. The goal is to move that archive into Gravity Forms so managers can see the history in the form's entries section and filter it alongside new requests.

Goal

Create entries in the existing Consultation Request form, avoid sending emails to customers, avoid triggering external feeds, store the original request date in a separate field, and mark the rows as archival. If some rows contain errors, collect a report and fix only the problematic records.

Preparation

First, the administrator creates a copy of the source spreadsheet. In that copy, the columns are renamed to match the meaning of the fields: Name, Email, Phone, Topic, Message, Original Date, Archive Status. Then the admin removes service rows, normalizes email formatting, and checks the dates. If the form does not yet contain a field for archive status, the admin adds a hidden or admin-only field that does not affect the public form but makes entry filtering easier.

Next, the administrator exports a short 10-row CSV. The test set includes a normal row, a row without a phone number, a row with an invalid email, a row containing non-English text, and a row with a long message. That mix immediately shows how the import handles different data conditions.

Import Steps

1. Open Forms - Import/Export - Import Entries.
2. Upload the test CSV and make sure the preview shows separate columns and displays non-English characters correctly.
3. Select the existing Consultation Request form. If the form does not appear, check search, trash, and the form's active status.
4. Map Name to the name field, Email to email, Phone to phone, Topic to subject, Message to the text field, and Original Date to a date field or a separate text field used for archival data.
5. Set any columns that are not needed in WordPress to Do Not Import so they do not create junk data.
6. On the Configure screen, disable user notifications and do not enable Process Feeds if the archive should not be sent to an external CRM.
7. Enable Continue Processing If Errors Occur for the test run so you can see a full report of problematic rows.
8. Start the import, open the summary, and then review the imported entries.

Verification

After the test import, compare the number of created entries with the expected count. Open 2 or 3 entries and inspect each field: the name should not end up in the email field, the date should not turn into plain text in the wrong column, the archive status should be saved, and the message should not be truncated. If the summary reports errors, open the log and fix the CSV instead of rerunning the same file unchanged.

Quick scenario summary: a good test import answers three questions: is the CSV being read correctly, are the fields mapped correctly, and are unwanted notifications or feeds staying off. Only after that is it worth uploading the full archive.

A Nuance About Updating Existing Entries

If the goal is not to create new entries but to update existing ones, the CSV must include an Entry ID column. The official FAQ on the product page explains an important behavior: when updating, the entry with the specified Entry ID is deleted and replaced by a new one. That is not the same as a lightweight field edit. So before attempting this, make a backup, test on a few rows, and make sure the CSV contains the full set of data that should remain in the entry after replacement.

Do not use Entry ID updates as a convenient way to tweak just a couple of columns unless you have verified the consequences for notes, metadata, integrations, and history. For bulk edits to existing Gravity Forms entries, it may sometimes make more sense to look at GravityActions or a controlled manual process based on export, edit, and re-import.

Creating a New Form from CSV

One of the most useful modes in GravityImport is form creation based on CSV. It is especially convenient when the spreadsheet already defines the future form: a participant list with registration fields, an application catalog, a questionnaire with many selectable options, or a list of questions and answers. Instead of building each field by hand, you can upload the CSV, choose to create a new form, and let the plugin suggest field types.

The documentation shows that after selecting Create a New Form, you assign a form name and can then override field types manually during the mapping step. That matters because automatic detection saves time, but it should never replace an editor's review of the form structure. If a column contains values like 1 and 0, the plugin may not know whether that means consent, status, or just a numeric code from an old system.

When a New Form Is Better Than an Existing One

Creating a new form makes sense if there is no suitable form yet or if the old spreadsheet is very different from the forms currently used on the site. For example, you may have a CSV with 30 columns for an event application, while no such form exists in Gravity Forms yet. In that case, the import can quickly create a basic structure, after which you refine the labels, required settings, help text, choice options, notifications, and appearance.

When You Should Not Create a Form Automatically

If the form needs to be public, multi-page, driven by conditional logic, powered by calculations, and backed by carefully tuned notifications, automatic creation from CSV should be treated only as a draft. The official FAQ states that GravityImport does not carry over conditional logic settings as a finished form structure. That means once the form is created, you still need to open it in the Gravity Forms editor and build the logic manually.

How to Review a New Form After Import

After the form is created, do not stop at checking the entries. Open the form itself and review the field types, labels, required settings, choice options, field order, and notifications. Then submit a test entry through the public side of the site or the Gravity Forms preview. If the form is only used as an archival database, a public display may not be necessary, but the structure should still make sense to the team.

Files, Users, Feeds, and Developer Extensions

Most imports end with mapping ordinary text fields. But GravityImport becomes more interesting because it supports more advanced cases: importing files from File Upload fields, assigning entries to users, triggering feeds, changing behavior with hooks, and controlling access to the import interface. These features are best enabled gradually.

Importing Uploaded Files

The official FAQ on the product page states that GravityImport can import files uploaded through a File Upload field: the plugin downloads the files from the source site and uploads them again during the import. In practice, that requires accessible URLs and proper upload permissions in WordPress. If a URL in the CSV points to a protected area, a temporary link, a deleted file, or a site that blocks access, the row may fail.

Before a large file import, run a separate test: one row with a small image, one row with a PDF, and one row with a missing file. That shows how the plugin reports file-related problems and which URLs are actually reachable from the WordPress server.

Assigning Entries to Users

The documentation includes a dedicated article on assigning entries to users during import, and the developer hooks reference shows a filter for the note user as well as capability-related behavior. If entries need to belong to specific users, decide in advance which column is the source: user email, username, ID, or some other key. Do not try to reconstruct this manually after the import. It is better to prepare a dedicated column and test several users with different roles.

Developer Hooks Without Unnecessary Risk

GravityImport documents many filters and actions. An ordinary administrator may never need them, but for a developer it is useful to know that you can normalize cell values through gravityview/import/column/data, change file source behavior through gravityview/import/column/file/source, control capability mapping through gravityview/import/rest/cap, and react to process statuses through gravityview/import/process/$status.

You should only add code when you have a recurring problem that cannot be solved by preparing the CSV correctly. For example, if an old system stores a checkbox as Y and N, it is often easier to normalize the values in the spreadsheet itself. But if the import happens every week and the source always sends the same nonstandard format, then a small filter may be justified.

add_filter( 'gravityview/import/column/data', function( $data, $column, $batch ) {
    // Normalize legacy CSV answers before checkbox validation.
    if ( is_string( $data ) ) {
        $normalized = mb_strtolower( trim( $data ) );
        if ( in_array( $normalized, array( 'yes', 'y' ), true ) ) {
            return 'Yes';
        }
        if ( in_array( $normalized, array( 'no', 'n' ), true ) ) {
            return '';
        }
    }

    return $data;
}, 10, 3 );

This example should not be placed inside plugin files. Put it in a safe location for custom snippets, or in a child theme if your team already uses that approach. After testing, remove the snippet or disable it if it was only needed for a one-time import. Do not leave data transformation enabled forever without documenting it for the team.

How to Verify the Result After Import

A successful message in the summary is the start of verification, not the end. The goal of the import is not just to make the plugin show a green status, but to make the entries useful without disrupting the site's workflows. That is why validation has to happen across several dimensions: counts, fields, filters, notifications, external integrations, permissions, and downstream use of the data.

Count Reconciliation

Compare three numbers: how many rows were in the CSV excluding the header, how many rows should have passed the import condition, and how many entries were actually created. If Conditional Import is enabled, the number of created entries does not have to match the row count. If Continue Processing If Errors Occur is enabled, some rows may have been skipped with errors. Record the result in your task notes so that if the import is repeated later, no one has to guess where the difference came from.

Field Checks

Open random entries from the beginning, middle, and end of the import. Do not inspect only the first row: in large CSV files, issues often appear later because of a different date format, an empty field, a nonstandard list value, or a long text block. Make sure the email landed in the email field, the phone number did not lose its leading plus sign, dates kept their meaning, and multiline text preserved line breaks where that matters.

Check the Impact on the Site

If the entries are displayed publicly through GravityView or another tool, open the relevant page and test filters, sorting, search, and access permissions. If the entries are used in reporting, run a control export. If feeds or notifications were enabled, inspect the external service logs and mail logs if those are available.

When to Repeat an Import

A repeat import is not always the right answer. If only some rows failed, it is better to export or copy just the problematic rows, fix them, and upload them as a separate file. Rerunning the full CSV can create duplicates if you are importing new entries without Entry ID values. If you are updating existing entries by Entry ID, rerunning the import is risky for a different reason: each entry may be replaced again with whatever is currently in the file.

Working Modes for Different Import Types

The same GravityImport interface can solve several different problems, but the settings should not be identical for all of them. The most common mistake is using one configuration for archived submissions, fresh leads, updates to existing entries, and new form creation. On the surface, all of these scenarios look similar: upload a CSV, choose a form, map the fields. In terms of consequences, they are very different.

To avoid turning every import into an experiment, choose a working mode in advance. It should answer four questions: are you creating new entries or updating existing ones, should external processors run, how strict should the validation be, and what counts as a successful result. Below is a practical matrix you can use before launch.

Batches Instead of One Huge Run

Even when the source file looks clean, large imports are easier to manage when split into meaningful batches. That does not necessarily mean cutting the file into sets of 50 rows. In many cases it makes more sense to segment by time period, status, source, or data type: old requests separately, active requests separately, rows with files separately, updates by Entry ID separately. That kind of segmentation makes reports easier to read and errors easier to roll back.

For example, if one CSV contains both rows with files and rows without them, start with the batch that does not include files. That lets you validate the basic mapping and required fields first. Then import a short batch containing files so you can confirm that the URLs are accessible and WordPress can store the attachments. After that, you can run the main body. If you import everything at once, it becomes much harder to tell whether the problem lies in the CSV, the files, validation, or server limits.

Duplicate Control

GravityImport should not become a way to blindly pour the same CSV into the system over and over. If you are creating new entries, rerunning the same file will create the same entries again unless you are using the Entry ID update workflow. So before every rerun, decide exactly what you are doing: fixing errors in a subset of rows, updating existing entries, or creating another batch of new data.

For archive imports, it helps to add a service field or entry metadata value that shows the import source, such as legacy_csv_2026_batch_01. You can hide that field from public display, but in the admin panel it makes filtering much easier. If the team later finds duplicates, it will be clear which batch created them.

Rollback and Logging

Rollback starts before an error happens, not after. The minimum set is: a backup, the original CSV, a test CSV, a screenshot or note showing which Configure options were enabled, the entry count before the import, and the summary after the import. If the site is business-critical, run the import on a staging copy first and only move a verified process to production.

GravityImport provides a summary and error log, but that does not replace your own operational notes. In those notes, record which file was uploaded, which form it targeted, which columns were skipped, whether feeds and notifications were enabled, how many entries were created, and how many rows failed. A month later, those notes are what will explain why the form contains archive entries without phone numbers or why some rows reached the CRM.

How to Build GravityImport into Your Team Workflow

Entry imports are often run by one person, but the consequences affect the whole team: managers work with the entries, marketing receives notifications, developers investigate errors, and the site owner asks why the stats changed. That is why GravityImport is better treated not as a button in the admin panel, but as part of a broader data management process.

Roles and Responsibility

Assign roles before the import starts. The person preparing the CSV is responsible for the structure, headers, and data hygiene. The WordPress administrator is responsible for the form, permissions, backup, and Configure settings. A developer only steps in when a documented hook, complex normalization, or an integration review is required. A manager validates the business meaning of the result: are the right fields visible, are the requests easy to filter, and were any important statuses lost.

This approach is especially important for agency sites, educational projects, and nonprofit organizations, where historical data often comes from several sources. GravityImport may be technically able to accept the CSV, but only the team knows what the Status column means, which rows are archival, which requests should never trigger emails, and which fields are needed for reporting.

The Import Document

For repeatable tasks, maintain a short import document. It can be a simple page in your team's knowledge base. List the data source, CSV export rules, required columns, target form, mapping, Configure settings, test sample, result checks, and what to do when errors occur. The document does not need to be long, but it should let another administrator repeat the process without guessing.

If the import involves personal data, add a minimization rule: do not bring fields into Gravity Forms that are no longer needed. A column can be set to Do Not Import if it serves no operational purpose and only increases risk. This is a simple way to reduce noise in entries and avoid storing extra data you do not need.

Testing on Staging and Production

The ideal process for a large site is staging first, then production. On staging, you test the CSV, mapping, Configure options, entries, public views, and integrations. On production, you repeat the same steps using the final file. If staging is not available, create at least a separate test form and a short test batch. Do not turn a live form with thousands of working entries into the site of your first experiment.

After the production import, do not delete the source files and notes right away. Keep them for as long as your internal audit and support process requires. If a user or manager later asks where an entry came from, you will be able to identify the batch and trace the source.

Common GravityImport Problems and How to Diagnose Them

Below is not a generic list of WordPress errors, but a set of issues directly tied to importing CSV data into Gravity Forms: the file does not load, the form does not appear, fields are mapped incorrectly, some rows fail validation, updates by Entry ID behave unexpectedly, or feeds and notifications trigger in ways you did not expect.

The CSV File Will Not Upload or the Columns Look Wrong

Symptom: the file fails to upload, the preview shows one long column, or non-English characters appear unreadable.

Cause: the export format is wrong, the delimiter is unexpected, the encoding is broken, service rows appear before the headers, or the file is not a real CSV. The official Upload CSV documentation makes it clear that Entry Importer supports CSV, and other formats need to be exported properly first.

What to check: open the file in an editor and make sure the first row contains real headers, not a note or explanation. Re-export it from Google Sheets, Excel, or LibreOffice. For multilingual data, verify UTF-8 using a small test file.

How to fix it: prepare a fresh CSV, remove empty and service rows, and replace vague headers with clear names. Do not try to fix mapping until the preview shows proper columns.

The Form You Need Does Not Appear in the List

Symptom: you know the form exists, but it is missing at the form selection step.

Cause: the form may be inactive, in the trash, or simply farther down the list and searchable. The form selection documentation explicitly calls out these checks.

What to check: open Forms in the admin panel, review the status filter, the trash, and the active toggle. Make sure the current user has enough permissions to work with forms and entries.

How to fix it: restore the form from the trash or reactivate it. If the import should go into a new form, use the new-form creation mode instead of mixing that up with a search for the old form.

Some Rows Fail Import Because of Validation

Symptom: the summary shows both created entries and errors, or it reports that some rows were not added.

Cause: the values do not match the field types or the form rules: an invalid date, a malformed email, a number stored in the wrong format, a dropdown value that is not among the allowed options, or an empty required field.

What to check: open the error log, find the row numbers, and compare them with the CSV. Inspect the specific field mentioned in the error. If Conditional Import is enabled, review the condition separately.

How to fix it: correct the source CSV and re-import only the failed rows. Do not make Skip Field Validation your first reaction if the entries will be used in active workflows.

Updating by Entry ID Replaced Something Unexpected

Symptom: after the import, an existing entry looks brand new, some older data is missing, or the history no longer makes sense.

Cause: updating existing entries in GravityImport requires an Entry ID column, and the official FAQ explains that the existing entry is deleted and replaced with a new one. If the CSV does not contain the full set of required fields, some data may disappear.

What to check: compare the backup or pre-import export with the CSV. Make sure the Entry ID belongs to the correct form, not to another form or another environment.

How to fix it: restore the data from backup or prepare a complete CSV for another controlled update. For small targeted edits, consider bulk-editing tools instead of replacing entries through import.

Notifications or Feeds Triggered Unnecessarily

Symptom: users received emails, the CRM received old leads, or an external service created duplicate records.

Cause: Email Notifications or Process Feeds was enabled on the Configure screen. The documentation confirms that Process Feeds can send every imported entry to the selected feeds, while still respecting feed conditions.

What to check: open the form settings, then review the list of notifications and feeds. Check which ones were enabled during the import and what conditions they use.

How to fix it: disable the unnecessary options before the next import. If the external service already received the data, the rollback has to happen in that service or through its logs, not inside GravityImport.

Limitations You Should Know in Advance

Every importer has boundaries. That does not make the product weak, but it does help you choose the right tool. GravityImport is strong at moving CSV data into Gravity Forms entries, creating a form from CSV structure, mapping fields, handling large files, and reporting errors. But it should not replace full form design, complex business-logic migration, or data auditing.

No Public CSV Import for Site Visitors

The official FAQ says that CSV import through GravityImport currently runs from the WordPress dashboard and requires admin access. So do not plan on a workflow where a client or event participant uploads a CSV from a public page using this interface. That kind of task requires a separate process with permission checks, file handling, moderation, and protection against harmful data.

Nested Forms Are Not Supported for Import

The FAQ states that importing Nested Form fields is not supported, and for that use case the developer recommends looking at GravityMigrate. If your data includes nested records, sketch the structure first: what is the parent entry, what is the child entry, and how are they linked. A simple CSV row cannot always represent that structure without losing meaning.

Calculations and Conditional Logic Do Not Become Magic

The product's official answers clearly separate data from form behavior. GravityImport can create a form based on CSV, but it does not bring over complex conditional logic settings as a finished form from another plugin. The developer hooks documentation also suggests that topics such as recalculating totals are still pending, so do not assume all complex calculations will automatically recompute after import. If the form relies on calculations, test them separately.

Large Files Still Require Discipline

The product page mentions thousands of entries and performance optimizations, but large imports still depend on hosting quality, available memory, execution time, CSV size, the number of feeds, and field complexity. Split the file into batches if the site runs on a weak hosting plan or if each row triggers additional processing. It is better to run three controlled imports by clear segments than one huge job with no easy way to understand where the failure occurred.

When GravityKit GravityImport Is the Right Choice

GravityKit GravityImport is worth using when you have a CSV with a clear structure, the site already runs on Gravity Forms, and the goal is to create or update entries through a guided interface with mapping, validation, and reporting. It is especially useful for migrating old submissions, archived registrations, participant lists, test datasets, and moving from spreadsheets to a more normal workflow inside the WordPress admin panel.

Before any large import, prepare the file, create a backup, run a test batch, review the Configure options, and only then launch the full CSV. If your use case matches that logic, you can move on to the download block and download GravityKit GravityImport to test it on your site.

If instead you need to migrate the entire structure of complex forms, nested records, feeds, uploads, and related settings between WordPress sites, look at GravityMigrate. If the data has already been imported and now needs bulk editing, evaluate GravityActions. The right choice here depends not on the product name, but on the direction of the data flow: CSV into entries, existing entries into bulk updates, or a full Gravity Forms ecosystem migration.