How to Auto-Filter a Table to Show Only the Current User's Data

Updated July 2026 • 6 min read • By Fahad Murtaza

Most frontend table use cases that involve logged-in users need to show each user only their own data. A driver checking their own loads, a customer reviewing their own orders, a form submitter viewing their own entries. Building this with a visible filter UI creates a security and UX problem: users see a filter and could remove it to access other people's data. TableCrafter's current-user auto-filter solves this by pre-filtering the table at the server before any data reaches the browser, with no filter UI exposed. 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,. JSON is the default data format for 96% of public REST APIs (ProgrammableWeb, 2024).

How Does the Current User Filter Work?

When the current-user filter is enabled on a table, TableCrafter injects a server-side condition into every data query for that table: only rows where the configured user-identifying field matches the ID of the currently logged-in WordPress user are returned. The filter is applied before the response leaves the server, no unfiltered data is ever sent to the browser and then hidden with CSS.

The user does not see a filter input for this condition. From their perspective, the table simply shows their data. There is nothing to remove, nothing to tamper with, and no way to retrieve other users' rows through the filter UI.

Prerequisites

Before enabling this feature, confirm the following:

• The table's data source is a Gravity Forms form. The per-user row filter described in this guide operates on the created_by column in the GF entry table and does not apply to other source types (CSV, Airtable, Google Sheets, etc.).
• For Gravity Forms, this is the Created By field (field ID: created_by), which Gravity Forms populates automatically with the WordPress user ID of whoever submitted the form. No custom field is needed.
• Users must have submitted the form while logged in. If a user submitted as a guest (not authenticated), the created_by field is empty (stored as 0) and TableCrafter cannot match that row to any logged-in user.
• The Gravity Forms form should have Require Login enabled to prevent guest submissions. This setting is on the form's Settings page in the GF admin and ensures every submission captures a valid user ID.

If you are not using Gravity Forms as the data source and still need per-user row scoping, the gravity_tables_column_value filter hook and custom SQL query extensions are the developer path for that requirement.

Step 1: How Do I Configure the User Field Mapping?

Open the table builder at TableCrafter → Tables → Edit for your Gravity Forms table. Scroll through the table-level settings panel until you reach the Filter by User section. Check the Show user only their own entries checkbox. Click Save Table.

There is no "User Identifier Field" dropdown to select. TableCrafter always uses the created_by column from the Gravity Forms entry table, which stores the WordPress user ID of whoever submitted the form. You do not need to add a created_by column to your form; Gravity Forms records it automatically on every entry.

This setting is a table-level boolean stored in the table's configuration. When the checkbox is enabled, the plugin injects AND e.created_by = %d into the SQL query for every non-admin user who requests data from that table. The shortcode does not require any additional parameters to activate this behavior; the filter is always in effect once the checkbox is saved. You cannot override it via shortcode parameters on a per-embed basis.

This filter only works for Gravity Forms-backed tables because it filters on the created_by field in the GF entry table. If your table connects to a non-GF source such as a CSV, Airtable, or Google Sheets, the per-user row filter described in this guide does not apply to that source type.

Step 2: How Do I Embed the Table on a Restricted Page?

[tablecrafter id="1"]

Because the filter is server-side and automatic, no additional shortcode parameters are needed. However, you must ensure the page itself is restricted to logged-in users. If a logged-out visitor reaches this page:

• TableCrafter detects no logged-in user and returns zero rows
• The table displays as empty, which is technically correct but confusing

Use your theme's page restrictions, a membership plugin, or a simple redirect rule to send logged-out visitors to the login page before they reach the table. Pair this with a WordPress conditional in your page template:

This step completes the connection between your data source and the TableCrafter table engine. Once saved, the plugin caches the connection credentials in the WordPress options table and uses them on every subsequent page load. If you update the source configuration later — for example, rotating an API key or changing a sheet URL — return to this step, enter the new value, and save again. The table updates immediately on next load without any shortcode changes.

if ( ! is_user_logged_in() ) {
    wp_redirect( wp_login_url( get_permalink() ) );
    exit;
}

How Admins See All Data?

Users with the WordPress administrator role are exempt from the current-user filter. When an admin visits the page, the table shows all rows from all users because the user ID condition is not injected into their query. This exemption is implemented in the plugin's AJAX handler via a hardcoded check: if current_user_can('manage_options') returns true, the created_by condition is skipped entirely.

This is intentional behavior for administrative oversight: the person managing the system should see everything. The exemption is not configurable from the admin UI; there is no "Admin Sees All" toggle to disable, and there is no "Roles That See All Rows" setting to list additional roles that should bypass the filter. These controls do not exist in the table builder.

Any WordPress user role that carries the manage_options capability will receive the same admin-level bypass automatically. If you have a custom Manager or Editor role that should see all users' data, you can grant it the manage_options capability using a role management plugin such as User Role Editor. If you want to keep a custom role restricted to its own rows, make sure it does not have manage_options in its capability set. There is no per-role configuration within TableCrafter itself to override this behavior.

How Does Combining With Other Features Work?

Current User Filter + Column Filters

Users can still use visible column filters while the current-user filter is active. The result is: this user's rows AND any column filter condition applied on top. For example, a driver viewing their own loads can still filter by delivery status, date range, or destination city. The current-user condition is always present as a base constraint applied server-side before any column filter; column filters then refine within that already-scoped result set. This means a user cannot accidentally remove the current-user constraint by manipulating a column filter. The two filter layers are independent: the current-user filter lives in the table configuration, and column filters are user-facing controls on the frontend. You can configure column filters per-column in the Filtering tab of each column card in the table builder.

Current User Filter + Inline Editing

When inline editing is enabled alongside the current-user filter, users can edit their own rows but cannot access rows belonging to other users because those rows are never returned by the server in the first place. There is no additional client-side permission check needed; the row simply does not exist in the DOM for a user who does not own it, so the inline edit controls are never rendered for it. From a security standpoint, this is the correct pattern: access control is enforced at the data query layer rather than through UI-level restrictions. Be aware that administrator-role users bypass the current-user filter and see all rows, so admins with inline editing enabled can edit any user's rows from the same table.

Current User Filter + Export

When the CSV export feature is enabled on a table that has the current-user filter active, the exported file contains only the rows visible to that user, which are only their own rows. The export respects the same server-side scoping as the table display; there is no way to export the full unfiltered dataset from the user-facing export button. Administrator-role users who export receive all rows because the current-user filter is bypassed for their session. This means the export button is safe to show to regular users in user-portal scenarios without risking data leakage from other users' submissions. Users can also combine a column filter with the export: they filter the table to a specific status or date range, then export, and the downloaded file reflects only their filtered subset.

How Does Use Cases This Pattern Fits Work?

The current-user filter pattern works for any multi-user system where different users own different records and should see only their own. The key requirement is that the Gravity Forms entry must include a field that captures the WordPress user ID of the person who submitted it — TableCrafter filters on that field to match the logged-in user's ID.

• Driver load portal: Each driver logs in and sees only the load submissions they created via the driver dropdown field. Dispatchers (administrator or custom role) see all drivers' loads without the user filter applied — role-based visibility rules determine which view a user gets.
• Customer order history: Each customer sees only their own WooCommerce orders or Gravity Forms submissions in a TableCrafter table, eliminating the need to build a custom My Account page section.
• Employee expense tracker: Employees submit expense claim forms and view only their own submitted expenses in the table. Finance managers and department heads see all employees' submissions via an administrator-only table configuration.
• Student assignment tracker: Students see only their own assignment submissions. Teachers and graders see the full class table, optionally filtered by student or assignment type using standard column filters alongside the current-user row filter.
• Volunteer shift log: Each volunteer sees their own logged hours; a coordinator sees all volunteers' records and can export the full dataset for reporting.

What Is Troubleshooting: Table Shows No Rows for a Logged-In User?

If a logged-in user visits the table and sees zero rows when they expect to see data:

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.

1. Confirm the user submitted the form while logged in. If they submitted as a guest, the created_by field is empty (stored as 0) and TableCrafter cannot match it to their current WordPress user ID.
2. Verify the Show user only their own entries checkbox is checked in the Filter by User section of the table builder and that the table was saved after enabling it.
3. For Gravity Forms, verify the form has Require Login enabled in GF form settings so all submissions capture a valid user ID. Without this, some entries may have created_by set to 0 (guest).

What Are the Next Steps?

The current-user auto-filter is the cleanest way to build a personal data portal without exposing filter controls. Once this is working correctly, several natural extensions are worth considering depending on your site's needs.

If users need to refine their own data further, enable column-level filters on the table. These work alongside the current-user filter: the user's rows are the base result set, and column filters narrow within that set. A driver viewing their own loads can still filter by delivery status or date range without seeing any other driver's data.

If users need to update their own entries directly from the table without going to the GF admin, enable inline editing. Because the user filter is server-side, users can only edit rows that belong to them; rows from other users are never in the DOM at all.

If you need to add the submitter's name or email as a visible column in the table, add the created_by system column from the field picker. TableCrafter automatically resolves the stored WordPress user ID to the user's display name when rendering that column, so visitors see a human-readable name rather than a numeric ID. This is described in more detail in the guide on showing user information in tables.