How to Restrict a WooCommerce Orders Table by WordPress Role

Updated July 2026 • 7 min read • By Fahad Murtaza

A single WooCommerce store typically needs at least three different views of order data: customers see only their own orders in read-only mode, shop managers see all orders and can edit status, and admins see everything including cost and margin columns. TableCrafter handles all three with separate table configurations and role-gated column visibility. This guide walks through each role configuration in full. 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. WooCommerce processes over 7 billion dollars in orders monthly across all installations (WooCommerce, 2024).

What Is the Three-Table Strategy?

The cleanest approach is to create three separate table configurations sharing the same WooCommerce Orders data source. Each config is tuned for one role's needs:

• Table A: Customer view, current-user-filtered, read-only, minimal columns
• Table B: Shop Manager view, all orders, status editable, no cost columns
• Table C: Admin view, all orders, all columns including cost/margin, bulk actions

You then place the appropriate shortcode on the appropriate page, with each page restricted to the right role. Alternatively, you can use a single page and render all three shortcodes, TableCrafter's own role checks ensure each user sees only the table they have permission to view.

After completing this step, verify the result by viewing the page as a logged-out visitor in an incognito window. This confirms the table behaves correctly for public visitors rather than reflecting admin-level permissions that may hide configuration issues during initial setup. Check both the rendered output and the browser console for any JavaScript errors.

What Is Role 1: Customer, Read-Only, Own Orders Only?

Table Configuration

Create a new table: WooCommerce Orders, Customer View. Data source: WooCommerce: Orders.

Columns

• order_id, linked to /my-account/view-order/{order_id}/
• order_date, date format
• order_status, badge display, no edit
• line_item_name, product name
• order_total, currency format

Do not include cost price, margin, internal notes, billing phone, or any business-internal fields.

Filters

Add one hidden filter:

• Source Field: customer_id
• Filter Type: Current User
• Visibility: Hidden

This filter is enforced server-side on every query. Customers cannot see other customers' orders regardless of what they do in the browser.

Access Settings

• Minimum role to view: Customer
• Roles that can edit: None
• No Access Message: Please log in to view your orders.

Shortcode

[tablecrafter id="5" search="true"]

Place on the My Account orders page or a standalone My Orders page.

The column mapping you define here is stored as a JSON configuration in the WordPress database. You can export this configuration using the TableCrafter export tool and import it to another table or another site. This is useful when replicating a table layout across multiple pages or when migrating a table to a staging environment for testing before going live.

What Is Role 2: Shop Manager, All Orders, Status Editable?

Table Configuration

Create a new table: WooCommerce Orders, Shop Manager. Data source: WooCommerce: Orders.

Columns

• order_id, linked to WooCommerce admin order detail: /wp-admin/post.php?post={order_id}&action=edit
• order_date, date format, default sort DESC
• Computed: {billing_first_name} {billing_last_name}, label: Customer
• billing_email, mailto link
• line_item_name, label: Product
• line_item_quantity, label: Qty
• order_status, badge display, inline editable dropdown, min role: Shop Manager
• order_total, currency format

Do not include cost price or margin columns in this config. Shop managers should see the sale price the customer paid, not the cost the business paid for the product.

Filters

• Status filter: Multi-select, default processing,on-hold
• Date range filter: default last 30 days

No current-user filter, shop managers see all orders.

Access Settings

• Minimum role to view: Shop Manager
• Roles that can edit: Shop Manager, Administrator
• No Access Message: Access restricted to shop managers and administrators.

Shortcode

[tablecrafter id="6" edit="true" filter="true" search="true" export="true"]

Place on a private page. Use WordPress's built-in page visibility (Password Protected or Private) or a membership plugin to add an additional layer of access control beyond TableCrafter's own role check.

What Is Role 3: Administrator, All Orders, All Columns?

Table Configuration

Create a new table: WooCommerce Orders, Admin. Data source: WooCommerce: Orders.

Columns

All columns from the Shop Manager config, plus:

• line_item_cost, label: Cost Price (if tracked via a cost-of-goods plugin like WooCommerce Cost of Goods or Profit Margin plugin)
• Computed: {order_total} - {line_item_cost}, label: Gross Profit
• payment_method_title, label: Payment Method
• customer_note, label: Customer Note
• Any internal order meta fields relevant to your operations

Bulk Actions

Enable Bulk Actions in the toolbar config for the admin table. Add these bulk actions:

• Mark as Completed, sets status to completed for all selected orders
• Mark as Processing
• Export Selected, exports only selected rows to CSV, not the entire filtered result set

Access Settings

• Minimum role to view: Administrator
• Roles that can edit: Administrator

Shortcode

[tablecrafter id="7" edit="true" filter="true" search="true" export="true"]

How Does Placing All Three Shortcodes Efficiently Work?

If you want a single page that adapts based on who is viewing it, you can place all three shortcodes on the same page. TableCrafter will render each table only if the current user meets its minimum role requirement. A customer visiting the page sees Table A only. A shop manager sees Tables A and B. An admin sees all three.

This approach works but can look odd, a shop manager would see both their management table and the customer orders table. The cleaner approach is to use three separate pages and redirect users to the appropriate page based on role using a plugin like Meow Login Redirects or a small filter in functions.php.

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.

How Does Column-Level Role Gating Work?

For cases where the Shop Manager and Admin views differ only in a few columns, you can use a single table config with column-level role gating instead of two separate configs:

In the column settings for a sensitive column (e.g., line_item_cost), set Minimum role to view this column to Administrator. Shop managers will see all other columns but not this one. The column does not appear in the table HTML at all for shop managers, it is not hidden by CSS.

Column-level role gating reduces the number of table configs to maintain but makes the single config more complex. For three clearly distinct views, separate configs are easier to reason about and audit.

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.

How Does Security Considerations Work?

• TableCrafter's role checks fire on every AJAX request, not just the initial page render. A shop manager cannot trigger an admin-only column by modifying AJAX parameters.
• The current-user filter for customer tables is enforced server-side. Customers cannot bypass it by modifying the shortcode or the request.
• Inline edit permissions are checked on the server when the edit request is received, independent of whether the edit UI was rendered. A customer-role user who somehow triggers an edit request will receive a permission-denied response.
• Export requests go through the same permission checks as table data requests. A customer can only export their own orders; a shop manager can export all orders.

What Is Summary: Three-Role Configuration at a Glance?

Each WooCommerce role gets a separate TableCrafter table configuration with different column sets, row visibility scopes, and shortcode attributes. This table summarizes the setup described throughout this guide:

• Customer — current-user filter (sees only their own orders), read-only, 5 columns visible (Order Number, Date, Items, Total, Status), no cost or margin data. Shortcode: [tablecrafter id="5" search="true"]
• Shop Manager — all orders visible, Status column inline-editable, 8 columns (adds Shipping Address, Payment Method, and Customer Name), export enabled, filter controls for Status and Date. Shortcode: [tablecrafter id="6" edit="true" filter="true" search="true" export="true"]
• Administrator — all orders visible, all columns including cost and margin, bulk actions (e.g. mark multiple orders as fulfilled), export enabled. Shortcode: [tablecrafter id="7" edit="true" filter="true" search="true" export="true"]

Each configuration is independent: changing the column set on the administrator table does not affect the customer table. You can also share the same underlying data source across all three configurations, which means any change to order data is reflected immediately in all three table views without any synchronization step.