How to Set Up Role-Based Table Access in WordPress with TableCrafter

Updated July 2026 • 7 min read • By Fahad Murtaza

TableCrafter enforces two distinct access layers on every table it renders: who is allowed to see the table at all, and who can edit cells inline. Getting both layers configured correctly is the foundation of any multi-role WordPress deployment, and it takes about ten minutes the first time through. 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, Excel, and JSON, role-based column visibility, and auto-refresh. Every table embeds on any page with a [tablecrafter] shortcode or the native Gutenberg block. REST APIs handle over 83% of all web API traffic as of 2025 (RapidAPI, 2025).

What Is the Two Access Layers Explained?

Before touching the admin UI, it helps to understand the model. TableCrafter separates visibility from editability:

• Viewer roles, any WordPress role listed here can see the rendered table on the frontend. Everyone else gets a blank area or a configurable access-denied message.
• Editor roles, a subset of viewer roles. Users in these roles see cells as clickable and editable inline. Users who can view but are not in an editor role see the same data as read-only text.

This two-layer model means you never have to choose between "public table" and "admin-only table." You can let subscribers read data while reserving editing for editors, or lock the table entirely to administrators while a public read-only version lives elsewhere on the page.

Step 1: How Do I Open the Table Configuration?

Navigate to TableCrafter → Tables in the WordPress admin sidebar. Either create a new table or click Edit on an existing one. The table builder opens with a tabbed interface. Click the Access & Permissions tab, it is the fourth tab by default.

This step is required before the table can render data. Skipping it or entering incorrect values will result in a connection error when the table first loads. Double-check the value by pasting it directly into the field rather than typing it manually to avoid whitespace or encoding issues.

TableCrafter re-fetches this data on each page load by default. If your data source updates infrequently and your site has significant traffic, enable the built-in caching option in the table's Performance tab. This stores the fetched data for a configurable number of minutes and serves it from WordPress transients, reducing API calls to the source and improving page load time for visitors.

Step 2: How Do I Set Allowed Viewer Roles?

The Allowed Viewer Roles field presents a multi-select checklist of every role registered in your WordPress installation. Stock WordPress ships with Subscriber, Contributor, Author, Editor, and Administrator. Custom roles from plugins such as WooCommerce (Customer, Shop Manager) or bbPress (Participant, Moderator) appear here automatically.

Check every role that should be able to see the table. Leave a role unchecked and WordPress users in that role will never see the table render, even if the shortcode is placed directly on a page they can access.

There is also a Guests (not logged in) checkbox at the top of the list. Enabling it makes the table publicly visible to unauthenticated visitors. Leave it unchecked for any table containing private or user-specific data.

Step 3: How Do I Set Allowed Editor Roles?

Directly below the viewer checklist is the Allowed Editor Roles checklist. Only roles already selected as viewers can be selected here, TableCrafter grays out non-viewer roles automatically to prevent configuration errors.

Select the roles that should be able to edit cell values inline. For most deployments this is Editor and Administrator at minimum. Contributors and Subscribers typically remain read-only.

The inline editing shortcode attribute must also be present for editing to activate. A user in an editor role visiting a table rendered with [tablecrafter id="1"] will still see read-only cells. Editing activates only when the shortcode includes edit="true":

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

The role check and the shortcode attribute are both required. Either one missing equals read-only output.

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 4: How Do I Configure the Access Denied Message?

Under the role checklists, the Access Denied Message field accepts plain text or HTML. This message renders in place of the table for any user whose role is not in the allowed viewer list. A sensible default is something like "Please log in to view this data" with a link to /wp-login.php. Leave it blank and TableCrafter renders nothing, no error, no message, just empty space.

If the result does not match expectations after saving, use the TableCrafter debug log (enable via TableCrafter Settings > Advanced > Debug Mode) to trace exactly which configuration value is being applied for the current request.

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.

Step 5: How Do I Save and Embed the Shortcode?

Click Save Table. Copy the shortcode from the top of the table builder, it will look like [tablecrafter id="4"], and paste it into any page, post, or widget area. The table ID is unique per table configuration and never changes after creation.

Test this step while logged in as a user with the target role to confirm the expected behavior. Logged-in admin users always see all columns and all rows regardless of role restrictions, which can mask visibility issues during initial configuration.

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.

How Does Testing with Two Browser Sessions Work?

The most reliable way to verify your role settings is a two-session test. Open your site in a standard browser window logged in as an Administrator. Open a second window in a private/incognito session and log in as a Subscriber (or whichever lower role you want to test).

Navigate to the page containing the shortcode in both windows simultaneously. In the admin window you should see the full table with clickable cells. In the subscriber window you should see either the read-only table (if Subscriber is in the viewer list) or the access denied message (if it is not).

If the subscriber window shows editable cells when it should not, double-check that Subscriber is absent from the Editor Roles list and that the server-side nonce validation is running, look at the Network tab in browser DevTools and confirm that save requests from the subscriber session return a 403 response.

How Do Role Hierarchy and Conflicts Work?

WordPress roles are not hierarchical in code, Administrator is not a superset of Editor at the capability level unless a plugin explicitly adds that inheritance. TableCrafter treats each role independently. If you check Editor as a viewer but forget to check Administrator, administrators will not see the table. Check all roles you intend to have access; do not assume higher roles inherit lower-role permissions.

The setting is stored in the WordPress options table under the table's configuration key. It does not modify the original data source and can be changed at any time without affecting the underlying records.

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.

What Are the Next Steps?

With the two access layers configured and tested, you are ready to move to column-level visibility. TableCrafter lets you hide individual columns from specific roles, useful for internal notes, cost fields, or score columns you never want certain roles to see even within a table they can access. See the guide on creating admin-only columns for the column-level configuration walkthrough.

This applies to all users who can view the table, regardless of role. Role-specific overrides can be set per column under the column Visibility settings. The table-level setting acts as the default for any column without a role override.

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.