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.

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. Every column opens the same settings panel: the same Visible to Roles checklist, the same column order drag-and-drop, the same label field, the same display type selector, and the same Save button at the top of the builder. This is deliberate: learning the column configuration workflow once means knowing it for every data source you will ever connect.

The source-agnostic design has a practical benefit beyond consistency. A table built around a Gravity Forms source can have its source switched to a REST API or WooCommerce adapter at a later date without losing any column visibility configuration. The role rules stay attached to the column definitions, not to the source adapter. This means you can migrate a table from one data backend to another and all role-based column visibility behavior carries over without reconfiguration. If you add a new data source integration in the future, it inherits the same column settings panel immediately, with no changes needed to the visibility configuration UI.

When Source-Specific Behavior Does Occur?

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

• 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 natural progression is to add more layers of access control around the same table. The first layer after column visibility is table-level access: restricting which users can view the table at all, regardless of which columns are visible. This is configured via the table's Access settings tab, where you can limit the table to logged-in users only, or to specific roles. A user who lacks table-level access never receives a table response from the server, no matter how the shortcode is embedded on the page.

The next layer is row-level filtering: showing each logged-in user only the rows that belong to them. This is useful for portals where individual users track their own submissions, orders, or assignments without seeing data that belongs to other users. TableCrafter handles this through the row filter settings, which can match a column value against the current user's ID or a user meta value at query time.

The guide on showing different table views to guests and logged-in users covers table-level access and the shortcode conditional approach, with examples for both. From there, explore the row-level filtering documentation for user-specific data patterns that build on top of what you have configured here.