Gravity Forms Multiple Forms - WordPress Plugin

How to Set Up Gravity Forms Multiple Forms for Linked Entries and Unified Views

Gravity Forms Multiple Forms becomes useful when a standard form and a standard entry display are no longer enough: data is collected across several Gravity Forms forms, but on the site it needs to appear as one linked table, catalog, internal register, or working list. This guide focuses on the practical side rather than a generic product overview: how to prepare the forms, where to enable the join, how a standard join differs from a strict match, how to verify the output, and why empty or duplicated rows sometimes appear on the page.

The add-on works inside the GravityKit ecosystem: GravityView handles the base entry display, while Multiple Forms adds the ability to pull entries from other forms into the main View based on a shared value. Think of it as a clean table join: for example, a "Customers" form stores the customer profile, an "Orders" form stores requests, and the View displays each order together with the customer's city, status, or internal category.

The most common mistake during the first setup is expecting the plugin to simply "merge" any entries from different forms into one combined list. It solves a narrower and more precise problem: it displays linked entries that share a common key. That is why this guide spends so much time on key fields, match validation, Search Bar configuration, Edit Entry limitations, and troubleshooting cases where the output looks odd simply because the relationship between forms was not designed clearly enough.

What Problem the Add-on Solves and Where It Is Truly Useful

In a standard Gravity Forms setup, each form exists as its own entry source. That works well as long as all the data belongs to one event: a contact form, questionnaire, registration request, or callback request. But in real projects, data is often spread across stages. A user may first create a profile, then submit a request, then add participants, documents, orders, or follow-up answers. If everything is stored in one huge form, that form becomes heavy, hard to complete, and difficult to manage. If you split the data across multiple forms, you run into a different problem: the team sees fragments instead of the full picture.

Gravity Forms Multiple Forms fills exactly that gap. It does not replace Gravity Forms, and it does not turn WordPress into a standalone CRM. Its role is more practical: it gives GravityView access to fields from several related forms so an administrator, manager, or authorized visitor can see a single View instead of manually comparing exports. This is especially useful for application catalogs, member dashboards, internal registers, participant lists, education projects, simple order systems, and any case where one entry adds context to another.

A typical example is a customer registration form paired with a request form. The registration form contains the name, email, city, and status. The request form contains the subject, date, priority, and the same email. If you link the forms by email, the View can display each request together with the customer's city and status. The team does not need to open two entry pages, export CSV files, or search for the customer manually. The value is not in the fact that there are "two forms," but in the fact that the relationship becomes a usable working screen.

There is also another class of use cases: parent and child forms. With Gravity Wiz Nested Forms, one parent form submission can create one parent entry and several child entries. Multiple Forms can use system meta fields such as the parent Entry ID and the child Parent Entry ID to display a team, participants, projects, line items, or other nested elements in one View. It is not a universal replacement for every database relationship, but for Gravity Forms workflows without custom development, this approach often covers most of what is needed.

The plugin is not for everyone. If you simply need to display entries from one form on a page, GravityView without Multiple Forms is enough. If you need to search entries across all forms only in the admin panel, GravitySearch is closer to that use case. If you need to combine entries from several completely unrelated forms into one shared list, Multiple Forms is not the best choice at the moment because it works through JOIN logic, not UNION logic. This limitation is important to understand before installation, otherwise the setup may look broken even when the plugin itself is technically working correctly.

Where the Add-on Works Best

The best use cases share three traits. First, the forms have a common key: an email, request number, parent entry ID, customer code, SKU, internal identifier, or another value that repeats across related entries. Second, the user needs a live screen on the site rather than an export: a table, list, cards, Layout Builder display, or another View. Third, the team understands which form is the primary one. Multiple Forms displays rows relative to the primary form, while the joined forms add extra data to those rows.

If those conditions are in place, the add-on can build practical screens: an order list with the customer city, an application register with profile data, a team list with players from Nested Forms, an internal course participant report, or an object catalog with extra attributes from a separate form. In all of these cases, the relationship has a business purpose rather than existing just to create a neat diagram.

Who Gravity Forms Multiple Forms Is For, and When Another Approach Is Better

This add-on is worth considering for site owners, agencies, and administrators who already use Gravity Forms and GravityView not just to collect submissions, but also to display entries. If the View serves as a working interface for the team or for visitors, joining related forms can significantly reduce manual work. The user opens one page and immediately sees the context: not only the request itself, but also the customer data, participant data, parent entry, or related object.

For agencies, this is especially convenient on projects where the client keeps asking for "one more field," "one more step," or "one more list," but it is still too early to rebuild the whole system from scratch. You can keep the forms relatively simple, then assemble a consolidated View afterward. This works particularly well when the data needs to remain in Gravity Forms, where notifications, confirmations, roles, integrations, imports, exports, and familiar support workflows are already in place.

For developers, the add-on is useful as a way to postpone custom SQL logic. GravityKit documentation includes developer hooks for Multiple Forms, including a filter for joined form conditions. That is not an invitation to start writing heavy custom hacks in the first release of a project, but it is a good sign: if the standard configuration gets you almost all the way there, a small targeted customization can be handled as a separate development task without breaking the View editor interface.

For beginners, Multiple Forms makes sense only when the task is defined carefully. If someone is still not sure how forms, entries, fields, Views, and Search Bar widgets differ, it is better to build a standard GravityView based on one form first. After that, the Multiple Forms workflow becomes much easier to understand: you will already know where to choose the data source, where to add fields to the Multiple Entries Layout, where to configure Single Entry, and how to verify the public output.

You should not start with this add-on if the project needs a full relational model with arbitrary relationships, complex permissions, transactions, reporting, and change history. WordPress, Gravity Forms, and GravityView can cover many practical use cases, but they do not replace proper data modeling. If the relationship between forms is critical for accounting, medical workflows, legal statuses, or financial operations, define the data model and the risks first. Multiple Forms can be part of the solution, but it should not be the only foundation for processes where a relationship error would be costly.

What to Check Before Installation and Your First View

Before installation, it is worth doing a quick audit. It takes less time than diagnosing empty rows, duplicates, and broken search later. The goal of the audit is to confirm that your forms can actually be joined, not just that you would like to see them side by side.

First, identify the relationship key. This is the field or meta value that allows an entry from the primary form to match an entry from the joined form. Email works only if it is entered the same way in both forms and does not change over time. An internal number is more reliable if you control how it is created. Entry ID and Parent Entry ID are a good fit for Nested Forms because the child entry stores a reference to the parent.

Next, decide which form will be the primary one. This determines the number of rows in the View and the meaning of empty values. If the primary form is "Orders," each row will be built around an order, and customer data will be pulled in as context. If the primary form is "Customers," rows will be built around customers, and orders may create multiple rows for a single customer or leave empty values where no orders exist. This is not a cosmetic setting, but a choice about what the report is supposed to mean.

Check compatibility within your active plugin stack. Multiple Forms requires Gravity Forms and GravityView, while some use cases may also depend on GravityView Pro, Advanced Filtering, or Gravity Wiz Nested Forms. If you plan to filter by fields from a joined form, confirm that Advanced Filtering is available and current in your setup. If Nested Forms is part of the plan, verify in advance that child entries are actually being created and that they store the Parent Entry ID.

Check the data separately as well. In a staging copy of the site, create 3 to 5 entries in each form: matching ones, non-matching ones, entries with an empty key, and entries with a repeated key. This lets you see how Left Join, Strict Entry Match, and potential duplicates behave before the View is exposed to users.

Practical rule: if you cannot explain in one sentence why an entry from form A should match an entry from form B, it is better to postpone the join setup and first bring the data into a clearer model.

Installation and Initial Verification in WordPress

Multiple Forms is installed from the GravityKit panel in WordPress. In a typical workflow, the administrator opens GravityKit, goes to Products & Licenses, finds the Multiple Forms add-on, and starts the installation. After activation, there is no separate public settings page for the plugin to look for: the main work happens inside the GravityView View editor, where you choose the data source, View type, join conditions, and the fields to display.

The first verification should stay small. Do not start with a large client registry containing dozens of fields. Create or choose two forms with simple fields, for example "Customer Registration" and "Order Form." In the first form, include email, name, and city. In the second, include email, request subject, and status. Add several test entries so that some email values match, some do not, and one email repeats. That small dataset will immediately show how the selected join logic affects the rows.

Then create a new View. Choose as the primary form the one the working list should be built around. If the task is to process requests, the request form should be primary. If the goal is to display a customer catalog with related events, the customer form may be primary. After choosing the View Type, add the join condition using the Add Join Condition button. In the first dropdown, choose the key from the primary form, then the form you want to join, then the field from the joined form that contains the same value.

After saving, check the field editor. The View should now allow you to add fields not only from the primary form, but also from the joined form. If you only see the primary form, first check whether the add-on is activated, whether the joined form still exists, and whether the View was saved after adding the condition. Older conflicting setups occasionally had issues with fields appearing, but current GravityView and Multiple Forms releases have addressed some of those bugs, so updating the core plugin stack is often the first safe troubleshooting step.

Minimum Post-Installation Check

After publishing the View, open the page as a regular user or in a private window. Do not stop at checking the editor. You need to verify the public-facing site because that is where empty fields, access rules, table styling, caching, and Search Bar behavior become visible.

1. Open the page with the View and confirm that rows from the primary form are displayed.
2. Find an entry that has a match in the joined form and verify that the additional fields are filled in.
3. Find an entry without a match and check whether the row remains visible. That is expected for a standard Left Join.
4. Enable Strict Entry Match and verify that rows without a matching pair disappear.
5. Clear the page cache if the result does not change after saving the View.

The normal state after basic setup is that you can predictably explain every row: why it is in the View, which form each field comes from, and which value was used to find the related entry.

Choosing the Primary Form and the Join Condition Without Confusion

The most important decision in Gravity Forms Multiple Forms is not the appearance of the table, but the choice of the primary form. The primary form answers the question, "Which rows should appear in the View at all?" The joined forms answer a different question: "What additional data should be shown next to each row?" If you mix up those roles, the View may save successfully, but its meaning will be wrong.

Imagine a training center website. There is a "Students" form that stores the student's name, email, and status. There is a "Course Enrollment" form that stores the course, request date, and the same email. If the manager wants to process course applications, the primary form should be "Course Enrollment." In that case, each row represents one application, and the student profile adds the status and city. If the coordinator wants to see the student list and understand who enrolled where, the primary form can be "Students." With the same set of forms, the final View will answer different questions.

The join condition should use a stable value. Email is convenient, but not perfect: a user may make a typo, use a work address in one form and a personal address in another, change their email, or enter it with an extra space. An internal ID is more reliable if it is passed through a hidden field or created automatically. For Nested Forms, the best anchor is the built-in relationship between the parent and child entry because it is created by the nested form logic, not typed by the user.

If the key is entered by a visitor, add restrictions at the Gravity Forms level. For email, use an Email field. For a request number, enforce one consistent format. For a unique value, use the No Duplicates setting if duplicates truly should be blocked within that form. This is not a Multiple Forms setting, but it directly affects the quality of the join. The cleaner the key, the fewer false blanks and unexpected duplicates you will get in the View.

When to Use Email, ID, or a System Meta Field

Email works well for customer-facing workflows where the same person fills out both forms and email acts as a stable identifier. It is convenient for applications, orders, registrations, and surveys, but it requires careful duplicate checks. If two people use the same department address, the join may produce an unexpected result.

Entry ID is a good fit when an entry from one form needs to become the parent for another entry. This is common in nested forms and step-by-step processes. The main advantage is that the value is created by the system and does not depend on how the user types text. The downside is that it has to be passed or selected correctly in the join condition.

A custom reference code is useful when the relationship extends beyond a single site: a request number from a CRM, a participant code, an object ID, or a SKU. It is best stored in a separate field, shown to administrators, and used consistently across all forms. If the code is created manually, add a short instruction for the team and periodically review entries without matches.

How to Read a Join Condition

A join condition is easiest to understand when you say it out loud: "For each entry from the primary form, find the entry in the second form where field X equals field Y." If that sentence sounds natural, the setup is usually clear. If you find yourself saying, "Something similar should probably match somewhere," then the data model is not ready yet.

In the View editor, add only one condition at first and verify the result. It is better to introduce multiple conditions only after the base relationship works. In the current Multiple Forms logic, multiple conditions on the same joined form are processed together, so they narrow the match rather than creating unrelated random pairs. That is useful when email alone is not enough and you also need to verify something like a project number or group status.

Left Join vs. Strict Entry Match: How to Choose the Right Display Mode

By default, Multiple Forms behaves like a Left Join: rows from the primary form remain visible even when there is no matching entry in the joined form. In that case, the joined form fields in the row will be empty. This behavior is useful for working lists where the absence of a related entry is itself an important signal. For example, a customer registered but has not yet submitted a request; the team needs to see the customer and understand that the next step has not happened.

Strict Entry Match changes the meaning of the output. When this setting is enabled, the View keeps only entries that have a match in the joined form. If multiple forms are involved, the row must have the required matches across all joined conditions. This mode is useful for reports that should show "completed relationships" only: requests with a profile, participants with confirmed registration, orders with a matching customer, or child entries with a valid parent.

The mode should not be chosen as a technical guess. Ask what an empty related section means. If that emptiness is useful for the workflow, keep the standard mode. If it gets in the way and users should see only fully matched rows, enable Strict Entry Match. After switching, always compare the row count before and after. A sharp drop in the list may be normal, or it may indicate that the shared key is stored differently across forms.

Making the Practical Choice

For internal request processing, it is often better to start with Left Join. It shows not only the ideal entries, but also process issues: the customer exists but the related request is missing; the request exists but no profile was found; child items failed to attach to the parent. A View like this can serve as a data quality control screen.

For a public catalog, Strict Entry Match is usually more appropriate. Visitors do not need to see cards with missing relationships, and empty columns can look like a broken website. If the View will be published for external users, first build it as an internal review screen, fix the mismatches, then enable the strict mode and verify the front-end page.

For reports involving multiple forms, build gradually. Add the second form and verify the matches, then add the third. If you join three or four sources at once, it becomes difficult to understand which condition removed a row in strict mode. A good Multiple Forms setup almost always starts with a small dataset that can be checked visually.

Fields, Layouts, and View Settings After the Forms Are Joined

Once the join is configured, the next step is working with the View content. In the GravityView editor, you add fields from the primary and joined forms to the Multiple Entries Layout, Single Entry Layout, and, if the use case allows it, the Edit Entry Layout. There is no reason to display everything that becomes available. A good linked View shows only the data that helps someone make a decision or take action.

For dense working lists, the Table layout is a good fit: rows, columns, sorting, and quick scanning. For customer cards, participant cards, or object cards, a List layout or Layout Builder may be better if it is available in your GravityView stack. For technical and administrative screens, it helps to add a Search Bar, Page Links, Page Size, and clear column labels. The user should be able to tell which data comes from the primary form and which comes from the joined form, even if they appear side by side in a single table.

Pay special attention to Custom Content. In a standard View, merge tags often let you quickly build a useful label. In Multiple Forms, there are limitations: merge tags from joined forms are not always available inside Custom Content that belongs to a different form. A more reliable approach is to add Custom Content from the same form whose fields you want to use, or to display important fields as separate columns. That may be less flashy, but it is more predictable and easier to maintain.

If the View allows front-end entry editing, do not automatically carry over habits from a simple View. Multiple Forms documentation notes that joined forms have their own edit links, and the Edit Entry tab may require a special approach. For a safe launch, first make the View read-only, verify the output, permissions, and search, and only then test editing for each related form separately.

Which Fields to Display First

Start with the minimum working set. In an applications table, that might be the entry ID, name or organization, email, status, submission date, one field from the joined form that adds context, and a link to the Single Entry page. If you add twenty columns right away, the user will lose track of the main relationship. Fields from the joined form are best grouped together and given clear names such as "Customer City," "Profile Status," "Parent Entry ID," or "Participant from Child Form."

For Single Entry, you can reveal more detail. For example, the list may show only the order and the customer status, while the individual entry page displays the full customer profile, request history, and edit links. This keeps noise out of the main table while preserving useful detail.

A Small CSS Tweak for Better Readability in a Linked Table

If your joined Table layout becomes too wide, do not start with heavy template rewrites. GravityView lets you add CSS in the Custom Code area for a specific View, and the documentation describes View-specific containers and table classes. To visually separate fields from the primary form and the joined form, you can use a small tweak after assigning clear custom CSS classes to your columns in the field settings.

/* Add this to the Custom CSS for a specific View.
   Set the column classes in the GravityView field settings. */
.gv-container .gv-template-table .linked-form-column {
  background: rgba(46, 125, 190, 0.08);
}

.gv-container .gv-template-table .linked-form-column:before {
  font-weight: 600;
}

.gv-container .gv-template-table td[data-label="Profile Status"]:empty:after {
  content: "no match";
  color: #8a6d3b;
  font-style: italic;
}

Check the result on the View page and at mobile width. If your theme already applies heavy table styling, it is better to keep the tweak limited to a background highlight or the empty-value label. The rollback is simple: remove the CSS from Custom Code and update the View. Do not edit GravityView, theme, or add-on files just for a change like this.

Practical Example: Requests and Customer Profiles in One Working List

Let us walk through a use case that clearly shows the value of Multiple Forms. The site has a "Customer Registration" form with fields for email, name, city, and membership status. Separately, there is an "Order Form" or "Support Request" form with fields for email, request topic, priority, and request status. The team wants to open a single View and see requests together with the customer's city and status so they can quickly filter requests by region and understand who needs priority handling.

Goal: build a View where each row corresponds to a request, while customer data is pulled from the registration form by email. This kind of screen works well for an internal page, a customer support team, a training coordinator, or a request manager.

Preparation: both forms should already include an Email field, and the values must match. In the registration form, it is a good idea to enable email uniqueness if one email should correspond to one profile. In the requests form, repeated requests can be allowed because one customer may submit multiple requests.

1. Create a new View and select the requests form as the primary form.
2. Choose the Table layout or another layout that fits a working list.
3. Add an Add Join Condition: the Email field from the primary form must match the Email field from the registration form.
4. In the Multiple Entries Layout, add the request topic, priority, and status from the primary form.
5. Add the city and membership status from the joined registration form.
6. Save the View and open it on a public page or in a restricted area of the site.
7. Create test entries: one request with an existing email, one request without a profile, and one profile without a request.

On the first pass, leave the View in the standard mode without Strict Entry Match. That way you will see requests that do not have a matching profile. This is useful: an empty city or empty customer status immediately shows that the email did not match or that the profile has not been created yet. Once the data is cleaned up, you can decide whether strict mode is appropriate. For an internal request queue, it is often better to keep empty profiles visible so the team can correct the data.

Verifying the Result

Verification should start with the data, not with the appearance. Open each test entry in the Gravity Forms admin panel and compare the email values. Then open the View and confirm that the row with the matching email displays fields from both forms. In standard mode, the row without a profile should show empty joined fields. If you enable Strict Entry Match, that row should disappear. That is your working proof that the join logic is behaving correctly.

If you use Advanced Filtering, add a condition based on a field from the joined form, such as city equals New York or membership status equals Active. In the current documentation, Advanced Filtering with Multiple Forms supports form selection in the condition builder, so the user can filter not only by fields from the primary form, but also by fields from the joined form. After saving, verify that the list actually narrows by customer profile data rather than only by request data.

Common pitfall: if the email repeats in the registration form, one request may join to multiple profiles and produce multiple rows. In that case, the issue is not the table design, but the quality of the key. The fix is to clean up duplicates, enforce uniqueness where appropriate, or choose a different relationship key.

Data Quality Control Before Publishing a Linked View

Even a perfectly configured join condition will not fix messy data. Multiple Forms displays whatever can be linked based on actual values. That is why it is worth doing a separate quality check on your keys before publishing. The purpose is not to find an attractive interface bug, but to prove that every row will behave predictably as new requests come in.

Start with a source map. Write down the primary form, the joined form, the relationship field in each form, who fills in that field, and whether the value can change after submission. If the field is filled in by a visitor, the risk is higher. If the value is generated by the system, the risk is lower. If the value is edited manually by a manager, you need a rule: what format to use, what to do when there is an error, and who is allowed to change an already linked entry.

The next step is checking for empty keys. An empty email, an empty request code, or an empty Parent Entry ID cannot produce a meaningful relationship. In a test View, leave Left Join enabled and temporarily display both key fields side by side. That is not always necessary in the final public version, but during setup it quickly reveals where the relationship is missing because of the data, not because of the plugin.

After that, check repeated keys. Repetition is not always bad. In a requests form, one email may appear dozens of times because the customer submitted several requests. But in a profile form, that same email may need to be unique. If the joined form contains multiple profiles with the same email, the working View will start duplicating rows. That is why uniqueness rules should be defined not in Multiple Forms, but in the form model itself: which field may repeat, and which one must remain unique.

A Test Set Worth Creating by Hand

You do not need hundreds of entries for verification. A small set is enough if each entry tests a separate case. Create one fully matching pair, one primary-form entry without a pair, one joined-form entry without a primary row, two joined entries with the same key, and one pair with a similar but not identical value. For example, This email address is being protected from spambots. You need JavaScript enabled to view it. and This email address is being protected from spambots. You need JavaScript enabled to view it. should count as different values unless you specifically added extra normalization.

After creating the set, run two checks. In standard mode, the View should display rows from the primary form, including the row without a pair. In strict mode, the View should show only the matched rows. If a repeated key produces two rows, document whether that is expected behavior. This simple matrix makes it easier to explain the result to the site owner without leaning on technical jargon.

At this stage, it is also useful to verify sorting. Multiple Forms and GravityView release history includes fixes related to sorting fields from joined forms. That does not mean sorting should be avoided, but it does mean it should be tested separately: sort by a column from the primary form, then by a column from the joined form, then by the field used for the join. If the result matters to daily work, do not leave it unverified.

How to Decide the View Is Ready

A linked View is ready for publication when it passes four questions. First: does the user understand what each row represents, whether that is a customer, request, child entry, or another object? Second: do empty values have a clear explanation instead of looking like a bug? Third: are duplicates either expected or resolved? Fourth: does the selected join mode match the task rather than being chosen by accident?

If even one of those questions remains unclear, do not publish the screen as final. Keep it restricted, add diagnostic fields, fix the keys, verify the filters, and only then remove the internal columns. This matters especially for pages where users can see personal data, request statuses, or internal team decisions.

Nested Forms: When the Parent and Child Entry Need to Become One Screen

Nested Forms is one of the clearest use cases for Multiple Forms. A nested form creates several child entries inside a single parent submission. For example, the parent form may store the team and the child form the players; the parent form may store the project and the child form the tasks; the parent form may store the request and the child form the line items or nested elements. In storage terms, these are separate entries, but the user expects to see them together.

GravityKit documentation explains this through the parent form Entry ID and the child form Parent Entry ID. When the user submits the parent form, one parent entry and several child form entries are created. Those child entries contain a meta relationship to the parent. Multiple Forms can use those values as the join condition and then add fields from both forms into a single View.

This is where the relationship direction matters most. If the primary form is the parent form, the View will be built around the parent entry, but if there are multiple child items, you may see several rows for the same parent. That is not necessarily an error: if the team has three players, the linked View may produce three rows because each child entry is a separate match. If you expected one row with a combined player list, verify whether your layout actually supports that kind of output without extra logic.

If the primary form is the child form, each row will correspond to one nested item, while the parent fields provide context. For a player list, task list, request line items, or participant list, this is often more convenient. The user sees each child object as its own row, while the team, project, or parent request remains visible next to it.

What to Verify in a Nested Forms Setup

First, make sure the child entries are actually being created. Open the child form entries in the Gravity Forms admin panel and find the meta value that points to the parent. If there are no child entries, Multiple Forms has nothing to join. If child entries exist but Parent Entry ID is empty or does not match, the issue is in the Nested Forms configuration or in the test data.

Then check your expectations for the number of rows. One parent with several child entries will often produce multiple rows in the View. That is normal for a working list of child items. If you need a compact parent screen where the child items appear as a nested list, verify your layout capabilities, Custom Content options, and merge tag limitations in advance. Do not promise the client "one row per parent" until you have seen the output using real test data.

When editing Nested Forms inside a View with joined forms, keep the known limitations in mind. If editing a nested field does not work inside a linked View, do not try to fix it with CSS or caching. First check the documented limitations, then decide whether you need a separate View for editing or a "summary for viewing, source form for editing" workflow.

Search, Filtering, and Visibility Control for Joined Forms

The Search Bar in GravityView and Multiple Forms deserves separate attention. According to the official documentation, global search through Search Everything can search connected forms. There is a limitation when searching by a specific field: individual fields from a joined form may not be available in the Search Bar the same way fields from the primary form are. That is why search should be planned before the user ever sees the finished page.

For simple public search across a linked View, start with Search Everything. It covers the use case of typing in an email, name, city, or part of a request and finding the matching row. But if the interface needs dedicated filters such as "Customer City," "Profile Status," or "Membership Status," look to Advanced Filtering. In the current documentation, Advanced Filtering with Multiple Forms adds form selection to the condition builder: first you choose the form, then the field, then the condition.

That changes how setups are approached in practice. In the past, administrators often duplicated an important field into the primary form just so the filter would work. Now, in some cases, the field can remain where it logically belongs and the View can still be filtered by the joined form. For example, the View is built around requests, but the filter shows only requests from customers in a specific city. The user sees a request list, while the condition pulls the city from the customer profile.

One useful Advanced Filtering feature is conditional field visibility. For example, you can add the Membership Level field from the customer form but display it only when Membership Status equals Active. In that kind of setup, the View stays clean: inactive customers do not show an extra detail, while active ones keep the needed context. Before publishing, test this using several entries, including an inactive customer, an active customer, and a request without a matching profile.

Testing the Search Bar and Filters

Create a separate test set. Enter a value that exists only in the primary form. Then a value that exists only in the joined form. Then a value that exists nowhere. If Advanced Filtering is in use, test each condition separately and then in combination. Do not mix search troubleshooting with join troubleshooting: first make sure the rows are linked correctly, then test how the filters narrow them.

If a filter does not return the expected entries, check three things. Was the correct form selected in the condition builder? Is Strict Entry Match enabled and already removing the row before filtering? Does the value match the field format, for example "NY" versus "New York" if the form stores the choice as a short code?

Security, Performance, and Careful Publication of Linked Data

Multiple Forms does not make data public on its own, but any View can become a public page if it is configured and embedded that way. That makes the main security question very simple: which fields are you displaying, and who is allowed to see them? A linked View can feel safe because the data is spread across forms, but once the forms are joined, one page may end up showing email addresses, city, status, internal IDs, manager comments, and edit links. A screen like that needs to be reviewed even more carefully than a standard table.

The first safe approach is to separate the internal View from the public View. The internal one can display relationship keys, statuses, diagnostic fields, and empty values. The public one should show only what the visitor actually needs. If the View contains personal data, use visibility settings, roles, page restrictions, or a restricted area of the site. Do not rely only on the idea that "nobody knows the link."

The same logic applies to performance: the more forms, fields, filters, and conditions you add, the heavier the queries and rendering become. Multiple Forms changelog entries have mentioned fixes related to query performance, sorting, and the display of related entries. That means the add-on is actively maintained, but it does not remove the need for reasonable limits: display the fields you actually need, use pagination, avoid building one View with hundreds of columns, and do not make a public page serve as your entire administrative reporting system.

Caching needs to be tested in practice. A page with a View may display dynamic data, while pages with forms have their own quirks around confirmations, AJAX, and protection against duplicate submissions. If the public page still shows old rows after you save the View, clear the page cache, temporarily disable optimization for that page, and test again in a private window. For forms that create key entries, avoid aggressive caching on the submission page, especially if you have already seen duplicates or unusual confirmations.

From an SEO perspective, a linked View usually should not be just an indexable table full of personal data. If it is a public catalog, think through the Single Entry pages, headings, empty states, table accessibility, and speed. If it is an internal register, block indexing through access control rather than relying only on a meta tag. Multiple Forms helps you assemble the data, but the decision to make it public is still an architectural one.

Safe publication starts with one question: "Who actually needs to see this field?" If a field is useful only for an administrator diagnosing a relationship, do not display it in a public View.

Launch Plan: From Staging Copy to Working Page

The most reliable way to launch Gravity Forms Multiple Forms is not to "install it and immediately hand it to users," but to go through a short prototype cycle. First, set up the relationship on a staging copy of the site or in a restricted draft. At this stage, the View can look rough: internal IDs, diagnostic columns, temporary labels, and small test datasets are all acceptable. The goal is to prove that the relationship logic works.

The second stage is a working prototype for the administrator. At this point, it makes sense to remove unnecessary fields, add clear column names, enable the right layout, configure the Search Bar or Advanced Filtering, and test the behavior at mobile width. If the View is intended for the team, show it to someone who will actually use it. Ask them to find an entry, filter by the needed status, open the Single Entry page, and explain which actions feel clear and which do not.

The third stage is permission control. Test the View under different roles: administrator, editor, logged-in user without special permissions, and guest. If the page is restricted, make sure a guest cannot see the View itself or access the data through a cached copy. If the View includes edit links, test separately that a user cannot open an entry from another form without having permission for it.

The fourth stage is basic load sanity. There is no need to run complex benchmarks, but you do need to look at real volume. If the forms contain many entries, enable pagination, limit the number of columns, and check how quickly the page loads after the cache is cleared. For a public catalog, it is usually better to start with a compact list and Single Entry pages than to dump every detail into one wide table.

The fifth stage is support rules. Document for the administrator where the View is located, which forms are linked, which field serves as the key, what Strict Entry Match means, and how to check empty joined fields. It is a small piece of documentation, but it greatly reduces the risk that another employee will delete the relationship field, rename the key, or assume repeated rows are just a theme bug a month later.

What Not to Do on Launch Day

Do not change the form structure, join conditions, public permissions, and visual styling all at once. If the View breaks after that kind of bundled change, it will be difficult to understand why. Separate the changes: first the relationship, then the fields, then the filters, then the permissions, then the design. Do not delete the old simple View until the linked screen has been tested against real tasks. Do not enable entry editing just because it was convenient in a standard GravityView setup. In a linked workflow, editing needs its own separate test.

If the site is already processing requests, warn the team before the transition. Users should understand that the new table may show more context, but it does not replace checking the source entries. During the first few days, it is helpful to keep a link to the original Gravity Forms Entries pages available for the administrator so they can quickly compare any disputed row with the source record.

Common Multiple Forms Issues and Troubleshooting

Most Multiple Forms issues are not caused by the plugin "not working," but by the fact that the View is honestly reflecting the consequences of the data model. Empty values, duplicates, unavailable search fields, and odd editing behavior can usually be explained through the relationship key, the selected primary form, Strict Entry Match mode, or known add-on limitations.

Fields from the Second Form Are Empty

Symptom: rows from the primary form are visible, but the columns from the joined form remain empty. Possible causes include no match on the key, the wrong field ID being selected, values differing because of spaces or formatting, or the primary form not being the one you actually intended to use.

Check two specific entries in the Gravity Forms admin panel. Copy the key value from the primary form and compare it to the value in the joined form. If it is an email, check capitalization, extra spaces, and different addresses. If it is an ID, make sure you are comparing the parent Entry ID to the Parent Entry ID, not two unrelated numeric fields.

The fix starts with the data. Bring the keys into the same format, recreate the test entries, and update the View. If the empty row should disappear from the public output, enable Strict Entry Match, but do not use it as a way to hide a real data problem on an internal screen.

The View Shows Duplicate Rows

Symptom: one entry from the primary form appears multiple times. In a "team - players" setup, this may be perfectly normal: one team has several players, and each child entry creates a separate match. In a "customer - profile" setup, it is often a sign of duplicates in the joined form.

Check how many entries in the second form share the same key. If a customer's email appears three times, a single request may end up with three matches. The fix depends on the business logic: delete or merge duplicates, enable No Duplicates for the field, replace email with an internal ID, or change the primary form if what you really need is a list of child items rather than a list of parents.

Rollback is worth considering when duplicates started only after you added a second join condition or a new joined form. Go back to one condition, verify the result, then add the extra relationships one at a time.

The Form Join Option or Joined Form Fields Are Not Visible

Symptom: the View editor does not show the button for adding a join condition, or after joining you cannot add fields from the second form. First, make sure Gravity Forms, GravityView, and Multiple Forms are active. Then confirm that you are editing an actual GravityView View, not a WordPress page or a Gravity Forms form.

If the add-on is active but the interface behaves strangely, update the GravityView and Multiple Forms stack in a test environment. Release history has included fixes related to fields appearing, the View editor, and fatal errors with joined data. Do not try to fix this manually in the database. If the issue still appears in a clean test View with two simple forms, collect screenshots and contact the developer's support team.

The Search Bar Does Not Search a Specific Field from the Joined Form

Symptom: global search finds something, but an individual field from the second form is unavailable in the Search Bar or does not filter the way you expect. This matches a known limitation: joined-form fields may be unavailable for specific field search, while global search works through Search Everything.

The fix is to choose the right tool. For simple search, use Search Everything. For conditions based on joined-form fields, use Advanced Filtering if it is available in your license and installed stack. If you need a complex public filtering interface across many related fields, verify it in a prototype before promising it to the client.

Unions Do Not Work Even Though You Need to "Combine All Entries"

Symptom: you want to display entries from form A and form B as independent rows in one list, but the setup requires a common key and does not produce the expected output. This is not a configuration error. Multiple Forms supports a JOIN use case, where entries are related by a shared value, not a UNION use case, where unrelated entries are simply combined into one stream.

Workarounds depend on the task. Sometimes it is better to create separate Views for each form and place them on the same page. Sometimes the data should be collected into one form with conditional logic. Sometimes a separate implementation using GFAPI or another tool is the right answer. Do not try to fake a UNION with a random shared key: that kind of View will be fragile and difficult to support.

Editing Linked Entries Does Not Work the Way It Does in a Standard View

Symptom: Edit Entry does not show the expected fields, edit links go to the wrong place, or merge tags are not parsed in the edit tab. Multiple Forms has confirmed limitations in this area. Each joined form has its own editing logic, and some familiar GravityView features behave differently inside a joined View.

The practical approach is to launch the linked View as a read-only screen first. Then add separate edit links for each form if needed, and verify user permissions. If Nested Forms editing does not work inside the linked View, use a separate View or the source form for editing. The rollback is to remove fields from the Edit Entry tab and keep the linked page as a view-only screen.

When Gravity Forms Multiple Forms Is the Right Choice

Gravity Forms Multiple Forms is worth using when you already have Gravity Forms, GravityView, and a clear relationship between several forms. The strongest use case is not "show everything at once," but building a working View around a specific question: which requests belong to which customers, which child entries belong to a parent, which orders should be shown only for active profiles, or which rows are missing a related entry and need review.

Before publishing, follow a short path: choose the primary form, confirm the shared key, build a minimal View, verify Left Join, then Strict Entry Match, add fields from the joined form, and only then bring in search, filters, editing, and CSS. On paper, that order may not look like the fastest one, but in practice it saves troubleshooting time and makes the result much easier for the team to understand.

If what you need is a linked front-end screen, this add-on is worth testing. If the task is closer to global admin search, a UNION-style list of unrelated forms, or a more complex database model, it is better to choose another tool before the project becomes dependent on an unsuitable setup. For a safe test, you can get the WordPress version, deploy it on a staging copy of the site, and start with two simple forms where every row can be checked by hand.

The main readiness criterion is not the number of settings and not how polished the table looks. A View is ready when the administrator can explain every row: where it came from, why it matched, why it did not match, which mode is showing it, and what the user is expected to do after seeing it.