How Auto-Refresh Interacts with Role Permissions in TableCrafter

Updated July 2026 • 6 min read • By Fahad Murtaza • By Fahad Murtaza

Auto-refresh in TableCrafter keeps your tables live without a page reload, pulling fresh data from Gravity Forms entries on a configurable AJAX interval. When you layer role-based permissions on top, the behavior becomes nuanced: the refresh cycle respects every permission boundary enforced at initial load, so a driver user polling every 30 seconds sees exactly the same rows and columns they would see on a full page load. This guide breaks down exactly how these two Pro features interact, what happens at each layer, and how to configure them so your tables stay live without leaking data. 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. In a 2024 study of business WordPress sites, 68% of teams needed non-admin users to update form data at least weekly (WP Engine Survey, 2024).

What Auto-Refresh Actually Does Under the Hood?

Auto-refresh is a Pro feature that issues a periodic AJAX request to wp-admin/admin-ajax.php using TableCrafter's gt_get_table_data action. The request carries the same nonce that was embedded in the page at initial render, plus the table_id and the user's current session cookies. The server processes that request through the exact same code path as the initial page load, including every nonce check, every capability check, and every row-level and column-level filter.

The configured interval is set per-table in the table builder under TableCrafter → Tables → Edit. You choose a polling interval in seconds (common values are 15, 30, or 60 seconds). Once the page loads, a JavaScript timer fires the AJAX call on that cadence, swaps the rendered table body with fresh markup, and re-attaches event listeners for inline editing and bulk actions. The user sees updated data without touching the browser.

What Is Role-Based Permissions in TableCrafter: Two Layers?

TableCrafter's role-based permissions system operates at two distinct levels, and understanding both is essential before configuring auto-refresh in multi-role environments.

Table-Level Access

In the table builder, the Permissions tab lets you specify which WordPress roles can view the table at all. If a user's role is not on the allowed list, the AJAX handler returns an access-denied response, even when the request arrives via the auto-refresh timer. The shortcode [tablecrafter id="X"] (also accepted as [tablecrafter id="X"] or [tablecrafter id="X"]) simply does not render for that user, and subsequent AJAX ticks return empty payloads rather than data.

Column-Level Visibility

Beyond table access, individual columns can be restricted to specific roles. An admin user might see a Carrier Rate column that a driver user never receives, not because the column is hidden client-side, but because the server strips it from the AJAX response before transmission. On every auto-refresh tick, the same column-level role check runs, so a column that should be invisible to a driver never appears in their DOM regardless of how many refresh cycles fire.

How the Refresh Cycle Respects Permission Boundaries?

Each auto-refresh tick follows this server-side sequence:

1. Nonce validation, the request nonce is verified against the logged-in user's session. An expired nonce stops the cycle and surfaces an error state in the table UI.
2. Capability check, the handler calls canCurrentUserViewTable() with the specific table_id passed in the request. This prevents role-escalation attempts where a user swaps the table ID in a crafted AJAX call.
3. Row-level filtering, if the table is configured to show only entries belonging to the current user (useful for driver-facing tables), the Gravity Forms query is scoped by created_by before results are returned.
4. Column filtering, columns not permitted for the current role are stripped from the result set.
5. Inline-edit capability check, if the user's role does not have inline editing enabled for this table, the returned markup omits edit affordances (click-to-edit cells, save buttons) even if auto-refresh is active.

Because every tick repeats this sequence, auto-refresh is not a side channel around permissions. A user who could not see a row at page load will not see it appear in a subsequent refresh.

How Do I Configure Auto-Refresh for Multi-Role Tables?

When the same table is embedded on a page visited by multiple roles, the refresh interval you choose affects server load. Each concurrent user generates one AJAX request per interval. For tables with tight intervals (15 seconds) and large user bases, this can add up. A practical configuration approach:

[tablecrafter id="12"]


[tablecrafter id="12"]

Both shortcodes reference the same table configuration (id="12"), but the server's column and row filters ensure each role sees only its permitted data. You do not need to create separate tables per role, permissions handle the differentiation.

If you want different refresh intervals for different audiences, create two table configurations in TableCrafter → Tables pointing at the same Gravity Forms form, with role permissions and refresh intervals configured separately for each. This is the recommended approach when admin users need near-real-time data (15-second interval) but driver users can tolerate a 60-second cadence.

How Do Inline Editing, Bulk Actions, and Auto-Refresh Together Work?

Auto-refresh and inline editing are both Pro features, and they can run simultaneously. When a user is actively editing a cell (the cell is in its open edit state), the auto-refresh timer pauses to avoid clobbering in-progress input. Once the user saves or cancels the edit, the timer resumes from the configured interval. This prevents the jarring experience of a table re-rendering while a user is typing.

Bulk actions, delete, CSV/Excel/PDF export, and column-fill, are also gated by role permissions. The auto-refresh cycle does not re-enable bulk actions for users whose roles lack those capabilities. If a driver role is configured as read-only for a given table, the bulk action toolbar is absent from every auto-refresh render, not just the first load.

Status badges (text-to-color mappings on categorical columns) and data bars (inline bar charts on numeric columns) are re-rendered on each refresh tick alongside the data. If a status value changes from Pending to Delivered between ticks, the badge color updates automatically when the refresh fires, no configuration required.

How Do Troubleshooting Auto-Refresh and Permission Issues Work?

When auto-refresh behaves unexpectedly in a permissioned environment, these are the most common root causes:

• Table ID ambiguity, if multiple table configurations exist for the same form, the AJAX handler must receive the specific table_id. Omitting it causes the handler to select from multiple records non-deterministically, which can result in inconsistent permission enforcement across refresh cycles. Always pass an explicit id attribute in your shortcode.
• Expired nonces, WordPress nonces expire after roughly 12 hours by default. For pages left open overnight (common in operational dashboards), the refresh cycle will begin returning nonce errors. Consider shortening the nonce lifetime or implementing a nonce-refresh mechanism for long-running sessions.
• Caching layer interference, page-level caches (NitroPack, WP Rocket, W3 Total Cache) can serve a cached page to a role that should not see the table at all. Exclude permissioned table pages from full-page caching, or use cache-busting rules for logged-in users. The AJAX endpoint itself bypasses page cache, but the initial page render may not.
• Column-level changes not reflecting, if you update column permissions in the table builder while users are active, the change takes effect on the next AJAX tick. Users do not need to reload the page, but there is up to one refresh-interval delay before the new column set appears.