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

Updated June 2026 • 7 min read

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.

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: 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.

Step 2: 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: 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.

Step 4: 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.

Step 5: 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.

Testing with Two Browser Sessions

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.

Role Hierarchy and Conflicts

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.

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.