How to Display Entries from Multiple Gravity Forms in One Table

Updated July 2026 • 6 min read • By Fahad Murtaza

TableCrafter creates one table configuration per Gravity Forms form, there is no single-table mode that merges entries from two different forms into one unified dataset. This is a deliberate architectural constraint, not an oversight. However, there are three practical patterns that give you multi-form visibility on a single page, and this guide covers all of them honestly, including their trade-offs. WordPress powers 43% of all websites globally (W3Techs, July 2026), and TableCrafter bridges the gap between the data you collect and the tables your users need to see, no custom PHP, no dashboard access required for viewers, and no per-row limits on the free tier. The free version on WordPress.org supports CSV, JSON, Google Sheets, and Excel. Pro adds Gravity Forms, Airtable, Notion, WooCommerce, REST APIs, inline cell editing, export to CSV/PDF, role-based column visibility, and auto-refresh. Every table embeds on any page with a [tablecrafter] shortcode or. JSON is the default data format for 96% of public REST APIs (ProgrammableWeb, 2024).

What Is the Constraint: One Form Per Table Config?

Each TableCrafter table configuration is tied to one Gravity Forms form ID. The reason is structural: different forms have different field schemas. Form A might have a "Budget" field that Form B does not. Merging them at the database query level would require a common schema, which would mean either leaving most cells empty or pre-defining a union schema manually.

For most use cases, the patterns below achieve what you actually need without the complexity of a true merge. Read through all three before deciding which fits your situation.

If this step produces unexpected output, check the source data directly in the connected system. TableCrafter passes data through without modification — if a cell displays an unexpected value, the source record contains that value. Use the TableCrafter debug log (Settings > Advanced > Debug Mode) to trace the exact query sent to the source and the raw response received, which narrows the diagnosis to either a source-side or rendering-side issue.

What Is Pattern 1: Two Shortcodes on One Page (Side by Side or Stacked)?

The simplest approach: create two separate table configurations (one per form) and place both shortcodes on the same page.

[tablecrafter id="1"]
[tablecrafter id="2"]

By default these render as two separate tables stacked vertically. Users scroll down from one to the other. This works well when the two forms capture related but distinct data, for example, a "New Client Intake" form and a "Project Kick-off" form on the same client dashboard page.

For a side-by-side layout, wrap each shortcode in a WordPress Columns block (in the Gutenberg editor) or an Elementor two-column section:

<!-- Using WordPress columns block -->
[columns]
  [column]
    [tablecrafter id="1"]
  [/column]
  [column]
    [tablecrafter id="2"]
  [/column]
[/columns]

The shortcodes themselves are standard, the layout is controlled entirely by your page builder or theme.

Trade-off: Each table has its own search bar and filters. Users cannot search across both tables simultaneously. Column headers are repeated. Exporting downloads two separate files.

What Is Pattern 2: Tabbed Interface?

When the two forms represent distinct categories of data and users typically want to view one or the other (not both at once), a tabbed layout is cleaner than stacking.

Most WordPress page builders (Elementor, Divi, Gutenberg with a tabs plugin) support tabbed sections. Place one table shortcode per tab:

• Tab 1 label: "Service Requests" → [tablecrafter id="1" search="true" filter="true"]
• Tab 2 label: "Feedback Submissions" → [tablecrafter id="2" search="true" filter="true"]

This is the most common multi-form pattern in client portals and membership sites. The tabs are labelled for the user, so they know which dataset they are looking at. Each table still has its own search and filters, which is appropriate since the two forms likely have different filterable fields anyway.

Trade-off: Same as Pattern 1, no cross-form search. But for tabbed data, this is usually the right behavior, not a limitation.

What Is Pattern 3: Lookup Field Merge (Advanced)?

This pattern achieves the closest thing to a true multi-form join. It requires planning at the form design stage, but it is powerful when done correctly.

The idea: one form is the "primary" form and one form is the "related" form. A field in the related form stores the Entry ID of the corresponding primary form entry. TableCrafter's lookup field system reads that relationship and can display fields from the related form inside the primary form's table column.

A concrete example: Form A is a "Client" form (name, company, contact email). Form B is a "Project" form (project name, start date, budget, client reference field). The "client reference" field on Form B stores the GF Entry ID of the matching client from Form A.

In your TableCrafter table for Form B, you configure a Lookup Column:

1. Click Add Lookup Column in the column builder.
2. Set Source Field to the "client reference" field (which stores the Entry ID).
3. Set Lookup Source to Gravity Forms and select Form A.
4. Set Display Field to the "Company Name" field from Form A.

The resulting table shows Project entries with a "Company Name" column whose value is fetched from the matching Client entry in Form A. The join happens at query time via a subquery, no data duplication, no caching required.

What this achieves: A project table that shows data from two forms in one view. Users see all project entries with the client company name pulled from a separate form.

What it does not achieve: A true union (all entries from Form A and all entries from Form B in the same row set). The lookup only enriches Form B rows with data from Form A, it does not merge row sets.

Trade-off: Requires planning the form relationship in advance. The lookup column is read-only (you cannot inline-edit a field that comes from a different form). For complex relationships, the query adds a measurable amount of load time on large datasets.

When to Use Each Pattern?

What Is Not Possible (Yet)?

A true union, showing entries from Form A and Form B in the same row set, with a shared search bar querying both simultaneously, is not currently a TableCrafter feature. This would require defining a mapping schema that aligns fields from both forms, which is a significant configuration surface. If this is your core requirement, consider consolidating your data collection into a single Gravity Form with conditional logic to show/hide sections based on the entry type, then using one TableCrafter table on the result.

The shortcode accepts all column and filter settings defined in the table builder as defaults, but you can override individual parameters inline. For example, `[tablecrafter id="1" per_page="25"]` overrides the default rows-per-page setting for this specific embed without changing the saved table configuration. This lets you reuse one table definition across multiple pages with different display requirements.

What Are the Next Steps?

Most multi-form display needs are satisfied by the tabbed pattern or the lookup field approach. If you are uncertain which applies to your situation, start with the tabbed approach, it is the fastest to implement and easiest to explain to clients. The lookup approach is worth the extra setup time when you have a genuine parent-child data relationship between two forms.