How to Show Only a User's Own Gravity Forms Entries in a Table

Updated July 2026 • 6 min read • By Fahad Murtaza

One of the most requested patterns in member-site and client-portal WordPress builds is showing each logged-in user a table of only their own form submissions. TableCrafter handles this with a single toggle, no custom PHP, no query filters, no separate plugin. Here is how to set it up correctly and what to watch out for. 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 the native Gutenberg block. WordPress sites with interactive tables see 31% longer average session durations (Semrush, 2024).

Why This Matters for Member Sites?

Without user-scoped filtering, every visitor to a shared table page would see every submission from every user. For anything sensitive, order history, support tickets, intake forms, application status, that is a data exposure problem. It also creates a confusing UX: a user with three submissions should not have to scroll past three thousand other people's records to find their own.

Gravity Forms itself stores the WordPress user ID on every authenticated submission in the created_by column of wp_gf_entry. TableCrafter reads this column and applies a WHERE created_by = current_user_id() constraint when the option is enabled. No data is sent to the browser and then filtered client-side, the filter happens at query time.

TableCrafter re-fetches this data on each page load by default. If your data source updates infrequently and your site has significant traffic, enable the built-in caching option in the table's Performance tab. This stores the fetched data for a configurable number of minutes and serves it from WordPress transients, reducing API calls to the source and improving page load time for visitors.

What Is Prerequisite: Logged-In Submission Capture?

This feature only works for entries that were submitted by a logged-in WordPress user. Gravity Forms stores the WordPress user ID of the submitter in the created_by column of the wp_gf_entry database table. When a user is not logged in at submission time, Gravity Forms stores 0 in that column. TableCrafter's per-user filter adds AND e.created_by = %d to the SQL query where %d is the current logged-in user's ID. An entry with created_by = 0 can never match any logged-in user's ID, so guest submissions will never appear in a user-scoped table regardless of whether other fields like email address happen to match.

To ensure this works reliably for your use case, enable Require Login on the Gravity Form that feeds this table. That setting is on the form's own Settings page in the GF admin. With it enabled, only authenticated users can submit the form, which guarantees every entry has a valid created_by value. If you need to support both guest and authenticated submissions on the same form, you will need two separate table configurations: one scoped to the current user for authenticated visitors, and a separate admin-only table for reviewing guest submissions.

How Do I Enable the Current User Filter?

Open the table configuration for your Gravity Forms-sourced table at TableCrafter > Tables > [Your Table] > Edit. Scroll down through the table settings panel until you reach the Filter by User section. Check the checkbox labeled Show user only their own entries. Click Save Table.

That is the entire configuration step. The shortcode itself does not need to change:

[tablecrafter id="1"]

The filter is stored in the table configuration, not in the shortcode. This means you cannot accidentally expose all entries by copy-pasting the shortcode somewhere else; the scope restriction travels with the table config. There is no shortcode parameter to override this setting on a per-embed basis.

What Happens to Unauthenticated Visitors?

When the current-user filter is enabled and a visitor who is not logged in reaches the page, TableCrafter displays an empty table with the message "Please log in to view your entries." You can customize this message under TableCrafter > Settings > Messages > Not Logged In Message.

A better pattern for most sites is to restrict the page itself to logged-in users using WordPress's built-in page visibility settings, a membership plugin, or a plugin like Members. That way unauthenticated visitors see a login page rather than an empty table. TableCrafter's empty-table message is a last-resort fallback, not the recommended gate.

The configuration you set here applies to every visitor who loads a page containing this table, regardless of whether they are logged in. Role-specific overrides for columns and rows are a separate layer and do not replace these global display settings. Apply global settings first, then add role restrictions as needed for tables that serve multiple user types.

What Is the Shortcode Parameter Approach?

The per-user entry filter (Show user only their own entries) is a table configuration setting and cannot be toggled via a shortcode parameter. There is no current_user shortcode attribute; adding it to the shortcode has no effect.

What the shortcode does support for user-related access control is the allowed_user_roles parameter, which gates who can see the table at all based on their WordPress role:

[tablecrafter id="1" allowed_user_roles="subscriber,editor"]

This restricts the table to users with the subscriber or editor role. Users with other roles (including logged-out visitors) see nothing. This is a visibility gate, not an entry scope: it does not filter which entries appear; it controls whether the table appears at all for a given user. Combine this with the table-level Show user only their own entries checkbox to achieve both access control (only subscribers can see the table) and entry scoping (subscribers only see their own rows). You can also set the same allowed_user_roles restriction in the table builder's User Permissions section instead of the shortcode, and that setting will apply to every embed of the table regardless of how the shortcode is written.

What Is Role-Based Scoping: Mixed Visibility Tables?

A common pattern in client portals is: regular users see only their own entries, while editors or managers see all entries. TableCrafter does not have a "Role Overrides" section or an "Add Role Override" control in the admin UI; there is no per-role override for the user filter within a single table configuration.

The built-in behavior covers one scenario automatically: administrator-role users (anyone with manage_options) always bypass the per-user filter and see all entries. For any other role that should see all entries, the practical solution is to create two separate table configurations from the same Gravity Forms form:

1. Create Table A with Show user only their own entries enabled and allowed_user_roles set to your subscriber or customer roles. Embed this on the member-facing page.
2. Create Table B with the user filter disabled and allowed_user_roles restricted to your editor or manager roles. Embed this on a separate admin-facing page.

Both tables point to the same Gravity Forms form and can share the same column configuration. Any entry edited in one view is reflected in both because they draw from the same underlying GF entry database. This two-table approach achieves role-based row visibility without any per-role override feature in the plugin itself.

How Do I Display the Username or User Info in the Table?

In a user-scoped table, showing the current user's own name is usually redundant. But in a table where administrators can see all entries, a "submitted by" column is essential for identifying whose row is whose. There are no "Submitted By (Display Name)" or "Submitted By (Email)" virtual columns in the TableCrafter column picker; those column names do not exist in the plugin.

The column that exists for this purpose is the created_by system field. In the column builder's field list, you will see created_by as a selectable field (labeled User by default). When you add it as a column, TableCrafter automatically resolves the stored WordPress user ID to the user's display name at render time using get_user_by('id', $user_id). Visitors see a human-readable name such as "Jane Smith", not a numeric user ID. If the user account has been deleted, the cell shows "User #N" where N is the stored ID.

The created_by column is read-only and cannot be edited inline because it is a system field set by Gravity Forms at submission time, not a user-editable form field. To show the user's email address alongside the display name, add a separate column for whatever field in your form captures the submitter's email address; there is no separate system-level email virtual column for the WordPress account email.

What Are the Common Use Cases?

Application Status Portal

A user submits a job application via Gravity Forms, including their name, the position applied for, and any supporting materials they uploaded. Your admin or hiring team updates the application status field on each entry using the Gravity Forms entry editor or, with TableCrafter Pro, via inline editing directly in the admin table. The applicant logs in and sees their own application row with the current status, such as "Under Review", "Interview Scheduled", or "Decision Made." They do not see other applicants' records. Because the filter is server-side, there is no way for the applicant to remove it and browse other submissions. The table updates in real time on page load, so the applicant always sees the most current status without needing to contact the hiring team to ask for an update.

Order or Booking History

A service provider builds a Gravity Forms booking intake form that captures the customer's name, service type, preferred date, and special requests. Once bookings are accepted and statuses updated by staff, customers can log in to a member portal page that embeds a TableCrafter table showing only their own booking records. The table is sorted by date descending by default, showing the most recent booking first. A date-range filter column lets customers narrow to a specific season or month if they have a long booking history. Cancellations and status changes made by staff in the GF entry editor are visible in the customer's table on their next page load without any additional steps from the customer or the admin.

Support Ticket Log

Users submit support requests via a Gravity Forms ticket form, including a description, priority level, and any attached screenshots. A TableCrafter table with the user filter enabled is embedded on a "My Support Tickets" page in the member area. Each user's table shows their own open and resolved tickets with columns for ticket number, subject, status, and date submitted. The support team uses a completely separate TableCrafter table without the user filter, accessible only from a wp-admin page or a staff-only WordPress page, to see and triage all incoming tickets across all users. Keeping the two tables separate avoids the complexity of trying to make a single table serve both audiences from the same URL, and it means the support team's view can include columns that would be confusing or sensitive to show end users.

How Does Testing Your Configuration Work?

Always test user-scoped tables with a dedicated test account at the subscriber role, not your admin account, since admins bypass the filter by default. Create a WordPress user at the Subscriber role, submit a test entry under that account, then visit the table page while logged in as that subscriber. You should see exactly one row.

Then log out and visit the same page. You should see the "please log in" message or be redirected, depending on how you have gated the page.

After completing this step, verify the result by viewing the page as a logged-out visitor in an incognito window. This confirms the table behaves correctly for public visitors rather than reflecting admin-level permissions that may hide configuration issues during initial setup. Check both the rendered output and the browser console for any JavaScript errors.

What Are the Next Steps?

With per-user filtering in place, the next logical enhancement depends on whether users need to do more than view their own data.

If users need to update their own submissions, for example, updating a profile field or correcting a booking detail, enable inline editing in the table configuration (Pro feature). With the user filter active, inline editing respects the same scoping: a user can only edit rows that the server returns to them, which are only their own rows. There is no additional permission check needed for that case because rows from other users never reach the DOM.

If you need to show the submitter's name as a visible column for admin users who see all rows, add the created_by system field as a column. It resolves automatically to the user's display name. For admin visibility of all entries, use a separate table configuration without the user filter, restricted to administrator roles via allowed_user_roles in the table's User Permissions settings.

If your use case requires users to export their own records, the built-in CSV export button in TableCrafter respects the current-user filter: when a user clicks export, the downloaded file contains only the rows visible in their filtered table, not the full dataset.