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:

• Your data source records include a field that stores the submitting or owning user's WordPress user ID
• For Gravity Forms, this is the Created By field (field ID: created_by), which Gravity Forms populates automatically with the user ID of whoever submitted the form
• For custom data sources, you must have a column mapped to a field that stores WordPress user IDs

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

Open the table builder at TableCrafter → Tables → Edit. In the table-level settings panel (not a specific column), find the Access Control section. You will see:

• Filter to Current User: Enable/disable toggle
• User Identifier Field: A dropdown to select which column in your table maps to the user ID

Enable the toggle and select the appropriate field. For Gravity Forms tables, select Created By (User ID). Click Save Table.

The shortcode does not require any additional parameters, the current-user filter is always active when enabled in the table settings. You cannot override it via shortcode parameters on a per-embed basis.

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.

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 by default. When an admin visits the page, the table shows all rows from all users, the user ID condition is not injected into their query.

This is intentional behavior for administrative oversight: the person managing the system should see everything. Admins also see an Owner column appear in the table (the user's display name from the user identifier field), making it clear whose rows they are viewing.

If you want admins to also be filtered to their own rows, for example, if admins are also data contributors and you want a consistent experience, you can disable the admin exemption in Access Control → Admin Sees All. Toggle it off and save.

Other user roles with manage_options capability also receive the admin exemption. If you have a custom Editor or Manager role that should see all data, grant it the manage_options capability or use the Roles That See All Rows setting to explicitly list additional roles that bypass the user filter.

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 filter condition. For example, a driver viewing their own loads can still filter by delivery status or date. The current-user condition is always present as a base constraint; column filters refine within it.

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. There is no client-side enforcement needed, the row simply does not exist in the DOM for users who do not own it.

Current User Filter + Export

When export is enabled, the exported file contains only the current user's rows, the same data visible in the table. Admins who export receive all rows. This means the export button is safe to show to regular users without risking data leakage.

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 and TableCrafter cannot match it to their current user ID.
2. Check that the User Identifier Field in the table builder points to the correct field. If it is set to a custom field that stores email addresses rather than user IDs, the integer comparison will fail.
3. For Gravity Forms, verify the form has Require Login enabled so all submissions capture a user ID.

What Are the Next Steps?

The current-user auto-filter is the cleanest way to build a personal data portal without exposing filter controls. For use cases where you need to send users directly to a pre-filtered view via a link, for example, a notification email that links to a table pre-filtered to a specific record or status, the next guide covers URL parameter pre-filtering.