How Column Role Visibility Works Across Different Data Sources in TableCrafter

Updated July 2026 • 7 min read • By Fahad Murtaza

One of the most common questions before adopting TableCrafter's role visibility features is whether they work the same way regardless of data source. The short answer is yes: column role visibility is a TableCrafter configuration layer that sits above the data source. The same settings, the same UI, the same shortcode produce the same access behavior whether data comes from Gravity Forms, WooCommerce, a REST API, or Airtable. This guide proves it with three concrete examples. 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]. Auto-refresh tables reduce page reload frequency by 89% in live-data dashboard deployments (Kinsta performance benchmarks, 2024).

How the Architecture Makes This Possible?

TableCrafter treats data sources as interchangeable adapters. A Gravity Forms source adapter fetches entry data. A WooCommerce source adapter fetches product data. A REST API adapter fetches JSON from an endpoint. An Airtable adapter fetches records via the Airtable API. In every case, the adapter delivers a normalized row-and-column dataset to TableCrafter's core.

Role visibility evaluation happens in the core, after data is fetched and before it is serialized into the AJAX response. The core does not know or care which adapter delivered the data. The column configuration, including Visible to Roles settings, is applied identically regardless of source.

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 Example 1: Gravity Forms, A Project Tracker?

The table source is a Gravity Forms form that collects project submissions: Project Name, Client, Status, Budget, Internal Margin, and Project Manager Notes.

Configuration: Create a new table in TableCrafter and select Gravity Forms as the source. Choose the project submission form. In the Columns tab, configure the following visibility:

• Project Name, visible to: Subscriber, Editor, Administrator
• Client, visible to: Subscriber, Editor, Administrator
• Status, visible to: Subscriber, Editor, Administrator
• Budget, visible to: Editor, Administrator
• Internal Margin, visible to: Administrator
• Project Manager Notes, visible to: Administrator

What Subscribers see: Three columns, Project Name, Client, Status. The table fetches Gravity Forms entry data via GFAPI and returns only the three permitted columns in the response payload for Subscriber-role users.

What Editors see: Four columns, Project Name, Client, Status, Budget. The Budget value comes directly from the Gravity Forms currency field, formatted according to the field's display settings.

What Administrators see: All six columns including Internal Margin and Project Manager Notes.

The shortcode is the same for all three users:

[tablecrafter id="2" filter="true" search="true" edit="true"]

What Is Example 2: WooCommerce, A Product Catalog with Pricing Tiers?

The table source is a WooCommerce product table showing SKU, Name, Category, Retail Price, Wholesale Price, Cost, and Stock Status.

Configuration: Create a table in TableCrafter, select WooCommerce Products as the source. In the Columns tab:

• SKU, visible to: Customer, Shop Manager, Administrator
• Name, visible to: Customer, Shop Manager, Administrator
• Category, visible to: Customer, Shop Manager, Administrator
• Retail Price, visible to: Customer, Shop Manager, Administrator
• Wholesale Price, visible to: Shop Manager, Administrator
• Cost, visible to: Administrator
• Stock Status, visible to: Customer, Shop Manager, Administrator

The WooCommerce adapter pulls product data using wc_get_products() internally. TableCrafter's permission layer then strips Cost from everyone except Administrators and strips Wholesale Price from Customers before the response is sent.

Verification: Log in as a WooCommerce Customer account. Open DevTools, go to the Network tab, trigger the table data load, and inspect the JSON response. The Cost field key is entirely absent from the columns array and from every row object. There is no null value, no placeholder, the field does not exist in the response for Customer-role users.

[tablecrafter id="9" filter="true" search="true"]

What Is Example 3: REST API, A CRM Contacts Table?

The table source is a REST API endpoint at https://crm.example.com/api/contacts that returns contact objects with fields: id, name, email, phone, company, lead_score, and internal_notes.

Configuration: Create a table, select REST API as the source, and enter the endpoint URL along with any required authentication headers. Map the JSON fields to TableCrafter columns in the Field Mapping tab. Then configure column visibility:

• name, visible to: Editor, Administrator
• email, visible to: Editor, Administrator
• phone, visible to: Editor, Administrator
• company, visible to: Editor, Administrator
• lead_score, visible to: Administrator
• internal_notes, visible to: Administrator

Notice the Subscriber role is not in any viewer list here, this is an internal CRM table locked to authenticated staff only.

The REST API adapter fetches all fields from the upstream endpoint (it must, to have the data available). TableCrafter's permission layer then applies visibility rules before returning data to the browser. Lead Score and Internal Notes never appear in any response to Editor-role users, even though the upstream API returned those fields to the TableCrafter server.

How Does Configuration Is Identical Across All Three Work?

Looking at the three examples together, the column configuration UI is exactly the same regardless of source. The only difference between them is which adapter you selected when creating the table. The Visible to Roles checklist, the column order controls, the column label fields, all identical. This is deliberate: learning column visibility once means knowing it for every data source you ever connect. 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

When Source-Specific Behavior Does Occur?

There are a few places where data source does matter, not for role visibility, but for related features:

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.

• Inline editing: Editing writes back to the source. A Gravity Forms source writes back to GF entries. A WooCommerce source writes back to product meta. A REST API source requires a writable endpoint configured in the source settings. The role visibility configuration for whether a user can edit a column is source-agnostic; the actual write mechanism is source-specific.
• Filter options: Dropdown filter choices are populated from the source field's configured options. A Gravity Forms select field uses its configured choices. A WooCommerce taxonomy uses product categories. A REST API field uses distinct values from the fetched dataset. Role visibility does not affect how filter options are generated.

What Are the Next Steps?

With a solid understanding of how column visibility applies across sources, the next feature to explore is table-level access for guest vs. logged-in users. The guide on showing different table views to guests and logged-in users walks through the shortcode conditional approach and the TableCrafter role setting approach, with examples for both.

The data source connection is checked on each page load. If the source becomes unavailable — for example, if an Airtable API key is revoked or a Google Sheet is unpublished — TableCrafter displays a configurable error message rather than an empty table, so site visitors receive feedback rather than a blank page.

This configuration interacts with any caching or CDN layer active on your WordPress installation. If you use WP Rocket, LiteSpeed Cache, or a CDN such as Cloudflare, flush the page cache after making this change to ensure the updated configuration is reflected in the cached HTML served to visitors. TableCrafter's server-side output is regenerated on the next uncached request.