Admin vs. User Column Visibility Settings in TableCrafter

Updated July 2026 • 6 min read • By Fahad Murtaza • By Fahad Murtaza

Column visibility in TableCrafter gives you granular control over what data different users see in your tables, from hiding sensitive internal fields from end users, to letting individual users personalize which columns they want on screen. This guide walks through both layers of visibility control, how they interact, and how to configure them correctly for your use case. 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. 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. Over 60,000 plugins are available on the WordPress.org plugin directory (WordPress.org, 2026).

How Does Two Distinct Layers of Visibility Control Work?

TableCrafter separates column visibility into two independent concepts that work at different levels:

• Admin-defined column visibility, set in the table builder and enforced server-side. Certain columns are simply never exposed to specific roles, regardless of user preference.
• User-controlled column visibility picker, a frontend UI element that lets authenticated users show or hide columns they are already permitted to see. This is a display preference, not a security gate.

Both layers are Pro features. The free tier renders all configured columns to all users with no per-role filtering or user-facing picker controls.

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.

How Does Admin-Defined Column Restrictions (Role-Based Permissions) Work?

The primary visibility gate lives in the table builder under TableCrafter → Tables → Edit. Each column card in the builder exposes a Visible to roles setting. When you restrict a column to specific WordPress roles, TableCrafter strips that column from the query response for any user whose role is not on the allowlist.

This is enforced inside the AJAX handler that serves table data at wp-admin/admin-ajax.php. The handler runs a capability check against the current user before building the column set, columns the user cannot see are never included in the JSON payload sent to the browser.

Configuring role-based column visibility

1. Go to TableCrafter → Tables and open the table you want to configure.
2. In the column list, click the column you want to restrict.
3. Under Permissions, locate the Visible to roles multi-select.
4. Select every role that should see this column. Leave it empty to inherit the table-level default (visible to all roles that can view the table).
5. Save the table. Changes take effect immediately, no cache flush needed for role-restricted columns.

Common use cases

The most practical applications of role-based column visibility fall into three categories: protecting sensitive financial or operational data from non-administrative roles; separating personally identifiable information from shared tables where multiple users of the same role can see each other's entries; and reducing visual complexity for end-user roles by stripping columns that are only meaningful to administrators. In each case, the goal is to ensure the data delivered to the browser contains only what the user is authorized to see, not merely what they are expected to look at. Column-level restrictions enforce this server-side so that no client-side workaround can reveal hidden columns.

• Hide internal cost or margin columns from customer-facing roles while keeping them visible to administrator and editor.
• Show a driver's personal contact details only to the administrator role, not to other drivers viewing a shared load table.
• Expose a raw Gravity Forms entry ID column only to admins for debugging, while regular users see a cleaner display.

How Does User-Controlled Column Visibility Picker Work?

Pro When enabled, the column visibility picker renders a small toggle panel above the table, often represented by a columns icon or a "Columns" button depending on your theme. Users click it to check or uncheck individual columns from their view.

This preference is stored per-user in the browser (localStorage by default) so their choice persists across page loads without requiring a database write per interaction. Because it is a client-side preference layer, it only operates on columns that were already delivered in the server response, a user cannot toggle on a column they do not have permission to see.

Enabling the column visibility picker

The column visibility picker is a toggle panel that renders above the table header, listing every column the current user is permitted to see (based on their role) and letting them check or uncheck individual columns from their view. The user's preference is stored in the browser's localStorage, so it persists across page reloads on the same device without requiring a database write per interaction. Because the picker operates only on columns already present in the server's AJAX response, it functions as a personalization tool rather than a security mechanism - a user cannot use the picker to reveal a column that was stripped server-side due to a role restriction. The picker is configured per table, not globally, which lets you enable it on tables where personalization is useful and leave it off on tables with fixed layouts where users should not control column order.

[tablecrafter id="12" column_picker="true"]

You can also enable it from the table builder UI under Display Options → Show column visibility picker, which writes the same setting to the table configuration record.

Setting default column visibility for users

You can pre-configure which columns appear visible by default when a user visits the table for the first time (before they have saved a personal preference). In the column builder, each column has a Visible by default toggle. Deselecting it means the column is hidden in the picker on first load but remains accessible, the user can turn it on whenever they want.

How the Two Layers Interact?

The interaction is straightforward once you understand the order of operations:

1. Server filters first. When a table loads, the AJAX handler builds the permitted column set for the current user based on role restrictions. Restricted columns are excluded from the response entirely.
2. Client renders the permitted set. The JavaScript receives only the columns the user is allowed to see and renders the table accordingly.
3. Picker operates on the rendered set. If the column picker is enabled, the user can then toggle visibility within the permitted set. They cannot add back columns that were excluded in step 1.

This means role-based restrictions are a hard security boundary, while the picker is a UX convenience layer on top.

Practical configuration example

Consider a load-tracking table used by both administrators and drivers. Administrators need to see the internal cost-per-mile column and the raw entry ID; drivers should only see their assigned loads and delivery status.

// Shortcode on the driver-facing page
[tablecrafter id="5" column_picker="true"]

// Shortcode on the admin-facing page (same table, different page, same config)
[tablecrafter id="5" column_picker="true"]

In the table builder, the column configuration would look like this:

• Load Number, Visible to roles: all, Visible by default: yes
• Pickup Date, Visible to roles: all, Visible by default: yes
• Delivery Status, Visible to roles: all, Visible by default: yes
• Cost Per Mile, Visible to roles: administrator only, Visible by default: yes
• Entry ID, Visible to roles: administrator only, Visible by default: no (hidden by default for admins too, but togglable)
• Driver Notes (Internal), Visible to roles: administrator, editor, Visible by default: yes

With this setup, a driver who visits the page receives a JSON payload containing only the first three columns. The cost per mile and entry ID never leave the server for that request. An administrator sees all six columns, with the entry ID hidden by default but available via the column picker.

How Do I Troubleshoot Visibility Issues?

If a column is not appearing as expected, work through these checks in order:

• Check the role restriction first. Log in as the affected user role and inspect the AJAX response in your browser's network panel. If the column is absent from the JSON, it is being filtered server-side, revisit the role configuration in the table builder.
• Check the column picker state. If the column appears in the AJAX response but not on screen, the user's picker preference is hiding it. Clearing localStorage for the site or resetting the picker will restore the default state.
• Check the "Visible by default" toggle. A column hidden by default will not appear for first-time visitors even if the user has permission. This is expected behavior, it is a default display preference, not a restriction.
• Check the shortcode. The column_picker="true" attribute must be present for the picker UI to render. If it is missing, users have no way to toggle columns even if the feature is nominally enabled in the builder.
• Check nonce expiry. All TableCrafter AJAX calls go to wp-admin/admin-ajax.php with nonce validation. A stale nonce (common after long idle sessions on cached pages) will cause the data request to fail entirely rather than return partial column data.