How to Restrict Table Export to Specific WordPress Roles

Updated July 2026 • 6 min read • By Fahad Murtaza

Not everyone who can view a table should be able to download its contents. A public directory table might be fine for browsing but inappropriate to export in bulk. An internal reporting table might be safe for employees to view but restricted to managers for export. TableCrafter's export permissions system controls exactly who sees the export button and who can actually trigger a download at the API level. 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 (.xlsx), and JSON, role-based column visibility, and auto-refresh. Every table embeds on any page with the [tablecrafter] shortcode or the native Gutenberg block.

Why Export Permissions Are a Separate Concern?

Table visibility and export access are independent settings in TableCrafter. A table can be fully visible to all users — including logged-out visitors — while export is restricted to authenticated users with a specific WordPress role. This separation exists because the ability to view data row-by-row and the ability to bulk-download the entire dataset represent meaningfully different levels of data access, even when the underlying data is the same.

This decoupling is the right design for most use cases:

• Public visitors can browse a product catalog or staff directory table without being able to export a competitor-usable bulk list of all products with pricing.
• Only administrators can download the full dataset for CRM import, while customers can still read the searchable table.
• Registered customers can export their own order history (row-level scope, filtered by current user) while other customers cannot export each other's orders.
• Managers can export team data for reporting; individual contributors see the same data but cannot download it.

Configure table view permissions under Access → Minimum role to view, and export permissions under Access → Minimum role to export. These can be set to different roles on the same table configuration.

How Do I Configure Export Permissions?

Export permissions are set per-table in the TableCrafter admin.

1. Go to TableCrafter > Tables and click Edit on the target table.
2. Open the Export tab.
3. Find the Who can export? setting.
4. Choose one of the available options.

The available export permission levels are:

• Everyone: Any visitor, logged in or not, can trigger an export.
• Logged-in users only: Any authenticated WordPress user can export, regardless of role.
• Specific roles: Only users with one or more selected WordPress roles can export. You select roles from a checkbox list that includes all roles registered on your site.
• Admins only: Shorthand for restricting export to users with the administrator role. Under the hood, TableCrafter checks the export_gravity_tables capability, which is granted to administrators by default via TC_Capabilities_Service.

What Happens When a User Cannot Export?

Export permission enforcement happens at two layers: the UI and the API.

UI Layer: Button Hidden

When a user views the table without export permission, the export button is simply not rendered in the table toolbar at all. The HTML served to that user contains no button element for export. There is no disabled state, no grayed-out control, and no explanatory message. Users with the export_gravity_tables capability see the export controls; users without it see the table but cannot initiate a download.

TableCrafter evaluates the current user's WordPress role against the configured export permission before rendering the table response. This check runs on the server, not in JavaScript, so the button is absent from the page source rather than merely hidden by CSS. A technically capable user inspecting the DOM will find no export button to interact with.

For the three available export formats, CSV, Excel (.xlsx), and JSON, the visibility decision is shared: if the user has the export_gravity_tables capability, the export controls appear for all three formats; if not, none appear. There is no per-format permission granularity at the UI level. Note that PDF output is not a server-generated export format: it uses the browser's print dialog and is therefore available to any user who can view the page, independent of the export permission setting.

API Layer: Request Blocked

Hiding the button is not sufficient security on its own, because a technically capable user could construct a direct HTTP request to the export endpoint. TableCrafter blocks this at the server level: the export API endpoint checks the current user's capabilities before generating the file.

If an unauthorized request hits the export endpoint, whether from a direct URL, a script, or a browser tool, the server returns a 403 Forbidden response. No file is generated. No data is returned. The check uses WordPress's native current_user_can() function against the required capability for the configured role.

How Does Combining Export Permissions with Row-Level Visibility Work?

TableCrafter supports row-level visibility rules that show users only their own records. For example, a table of orders might show each customer only their own orders. When export permissions and row-level visibility are both configured:

• A customer with export permission downloads only their own rows.
• An administrator with export permission downloads all rows (because row-level visibility is typically bypassed for admin roles).

This combination gives you fine-grained control: customers can self-service their own data export without seeing anyone else's data.

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.

How Does Permission Configuration Examples Work?

How Does Checking Current User Role in WordPress Work?

If you are unsure what role a specific user on your site has, check it in WordPress Admin > Users. Each user's role appears in the Role column. The roles available in the TableCrafter export permission selector match whatever roles are registered on your WordPress installation, including custom roles added by membership plugins or other tools.

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.

Auditing export access

TableCrafter does not currently log export events to a database audit trail by default. If you need a record of who exported what and when, consider adding a WordPress activity log plugin (such as WP Activity Log or Simple History) alongside TableCrafter. These plugins hook into WordPress's action system and can capture custom events fired by TableCrafter, including the export trigger action that fires when a user initiates a CSV, Excel (.xlsx), or JSON export.

To set up basic export auditing: install an activity log plugin, configure it to track custom plugin actions, and look for the tablecrafter_export_triggered action hook that fires with the table ID and user ID as parameters. The log then records the timestamp, user display name, user role, and table name for each export event. This approach works without modifying TableCrafter files and survives plugin updates.

If you need stricter export controls — for example, limiting exports to specific tables for specific users rather than a blanket minimum-role rule — contact TableCrafter support about per-table per-user export permission overrides, which are available as a configuration option in Pro plans.

What Are the Next Steps?

With export permissions locked down by role, you can safely enable export on tables that contain sensitive data without exposing bulk download capability to unintended users. The export_gravity_tables WordPress capability, granted by default to administrator and editor roles via TC_Capabilities_Service, controls who can trigger a download. You can revoke it from editors or grant it to additional custom roles using a capability management plugin if the default role set does not match your access model.

From here, consider a few natural extensions. First, combine row-level visibility rules with export permissions so that users who can export only receive the rows they are permitted to see. This is particularly useful for customer-facing tables where each user owns a subset of the data and should not be able to bulk-download records belonging to others. Second, test the configuration from an incognito browser session using a test account with a restricted role, confirming both that the button is absent from the page HTML and that a direct POST to the export endpoint returns a 403 response. Third, review the three export formats: CSV, Excel (.xlsx), and JSON are each available when export is enabled. The AJAX action for export requests is gt_export_table. Note that PDF output is browser print only, not a server-generated format, so it is not controlled by the export permission setting.