How to Edit WooCommerce Order Status Inline from a Frontend Table

Updated July 2026 • 7 min read • By Fahad Murtaza

TableCrafter's inline editing for WooCommerce orders lets shop managers change order status directly from a frontend table cell, no clicking into the order detail page, no WooCommerce admin navigation. The status change writes back through the WooCommerce order API, which means all the same hooks, automations, and customer emails fire exactly as they would from the WooCommerce admin. 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/PDF, role-based column visibility, and auto-refresh. Every table embeds on any page with a [tablecrafter] shortcode or the native. WooCommerce powers over 6 million live online stores (BuiltWith, 2026).

How Does Write-Back Work?

When a user changes a status value in a TableCrafter inline edit cell, the plugin does not write directly to the database. Instead it calls $order->update_status() with the new status, which is the canonical WooCommerce order API method. This means:

• The woocommerce_order_status_changed action hook fires
• Status transition hooks fire (e.g., woocommerce_order_status_processing_to_completed)
• WooCommerce sends the appropriate customer email (e.g., Order Completed email)
• Third-party plugins listening to status transitions (shipping plugins, CRM integrations, inventory tools) receive the change the same way they would from the WooCommerce admin

This is a meaningful distinction from plugins that write status changes directly to the database row, which bypass all WooCommerce hooks.

Step 1: How Do I Enable Inline Editing on the Status Column?

In your table config, open the Columns tab and find the order_status column. Open its settings and locate the Edit sub-panel:

• Toggle Allow inline edit on
• Edit type: Dropdown (the correct type for a status field, presents a dropdown of valid status options rather than a free-text field that could accept invalid values)
• Options source: Auto (reads WooCommerce's registered order statuses programmatically, so if you add custom statuses via a plugin, they appear in the dropdown automatically)
• Minimum role to edit this field: Shop Manager (only users with at least the Shop Manager role can change order status; customer-role users viewing the same table see the status as read-only text)

Save the column settings and save the table config. After saving, the edit settings are stored in the table configuration and apply immediately on the next page load, no cache flush is required. The change is reflected across all pages that embed this table ID using the edit="true" shortcode attribute.

Step 2: How Do I Configure Role Gating?

TableCrafter applies two independent layers of role checking for inline edits:

1. Table-level edit permission: Set in Access → Roles that can edit. This gates whether the edit UI appears at all.
2. Column-level edit permission: Set per field in the column's Edit sub-panel. This gates whether a specific column is editable even for users who can edit the table.

For a typical WooCommerce setup, configure both levels:

• Table-level: Administrator, Shop Manager
• Column-level for order_status: Administrator, Shop Manager
• Column-level for order_total, billing_email, etc.: Leave edit disabled, these should never be changed inline

A customer-role user visiting the page sees the table in read-only mode. The inline edit controls do not render in their browser at all, they are not hidden by CSS, they are not output by the server.

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 3: How Do I Place the Shortcode with Edit Enabled?

Edit the page where you want the WooCommerce order management table and add a Shortcode block or Custom HTML block. Paste:

[tablecrafter id="3" edit="true" filter="true"]

The edit="true" attribute enables the frontend edit mode globally for this embed. Without it, the table renders read-only regardless of the table config's column-level edit settings, you must explicitly activate edit mode at the shortcode level. This design allows you to embed the same table configuration on multiple pages with different behaviors: read-only on a public-facing order summary page (no edit="true"), editable on a private management page (edit="true" present), using the same table ID and the same column configuration. No separate table config is required for the two views.

After publishing, verify the order management table is accessible to Shop Manager accounts but not to Customer-role accounts by testing with accounts at each role level. If a Customer-role user can see the table, check the "Minimum role to view" setting in the table config's Access tab, it should be set to Shop Manager or higher for this use case.

How Does the Inline Edit UX Work?

In edit mode, the order_status column renders each cell as a badge with a small edit icon. When a shop manager clicks the cell:

1. The badge is replaced by a dropdown select showing all available WooCommerce statuses
2. The current status is pre-selected
3. The manager selects the new status
4. A confirm checkmark (save) and an X (cancel) appear next to the dropdown
5. Clicking the checkmark sends an AJAX request to TableCrafter's REST endpoint
6. TableCrafter calls $order->update_status() server-side
7. On success, the cell reverts to badge display showing the new status
8. On failure, an error toast appears and the cell reverts to the original value

The entire interaction happens without a page reload.

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.

What Status Changes Trigger in WooCommerce?

Different status transitions trigger different WooCommerce behaviours. Understanding this is important before giving shop managers inline edit access:

Processing → Completed

This is the most common transition shop managers perform: confirming that an order has shipped or been fulfilled. When $order->update_status('completed') is called, WooCommerce fires the woocommerce_order_status_completed action hook, which triggers several downstream effects in a single pass. The Order Completed email is queued and sent to the customer's billing address, containing the order summary and any download links for digital products. This email fires even when the status change originates from the TableCrafter frontend table rather than the WooCommerce admin, because the code path goes through the same $order->update_status() method in both cases.

• Fires woocommerce_order_status_completed
• Sends Order Completed email to customer
• If you use a shipping plugin, this may mark the shipment as delivered

For sites using WooCommerce Subscriptions or WooCommerce Points and Rewards, order completion also triggers those plugins' own hooks. Before enabling shop managers to use inline editing in production, test this transition in a staging environment to confirm that no duplicate notifications, unintended subscription renewals, or loyalty point awards are triggered.

Any Status → Refunded

The Refunded status is frequently misunderstood: it is an administrative label indicating that a refund has been issued or is intended, not an instruction to the payment gateway to move money. When $order->update_status('refunded') is called from the TableCrafter table, WooCommerce fires woocommerce_order_status_refunded, sends the Order Refunded email to the customer, and records the status in the order history. The actual money movement back to the customer must be processed separately, either through the WooCommerce order detail screen using the Refund button (which connects to the payment gateway's refund API), or directly in your payment gateway's dashboard.

• Fires woocommerce_order_status_refunded
• Does not automatically process a payment refund, WooCommerce status and payment refund are separate operations
• Sends Order Refunded email to customer

Because the customer receives a refund email immediately on status change, configure this transition carefully. Consider restricting the Refunded status to the Administrator role only (not Shop Manager) using the column-level minimum role setting in the inline edit configuration, so only senior staff can trigger the notification. If you set status to Refunded by mistake, the customer email has already sent, there is no recall mechanism.

Any Status → Cancelled

Cancellation has side effects that extend well beyond the status label, making it one of the higher-impact transitions to expose through inline editing. The most significant is stock restoration: if WooCommerce stock management is active and the Restore stock when order is cancelled option is enabled in WooCommerce settings, cancelling an order releases the reserved inventory back to the available count. This happens synchronously when the status change fires, so the stock level updates immediately. In high-traffic stores this can make previously reserved items available for new purchases within seconds of cancellation.

• Fires woocommerce_order_status_cancelled
• Restores stock if WooCommerce stock management is enabled and Restore stock when order is cancelled is turned on in WooCommerce settings
• Sends Cancelled Order email to customer

The Cancelled Order notification goes to the customer's billing address immediately. The store admin also receives the New Cancelled Order admin email if that notification is enabled in WooCommerce settings. Both emails fire through the normal WooCommerce email queue, identical to the behavior from the WooCommerce admin order screen.

How Does Limiting Which Status Transitions Are Allowed Work?

If you want to restrict the dropdown to only valid forward transitions (for example, prevent moving an order backwards from Completed to Processing), use the Allowed Values setting in the column's edit config. Enter the slugs of the statuses you want to appear in the dropdown:

processing, on-hold, completed, cancelled, refunded

Leave out pending and failed if you never want shop managers to set those manually. The column will display any status value (including pending and failed) in read mode, but the edit dropdown only offers the specified options.

The Allowed Values list is stored per-column in the table configuration and applies uniformly to all roles permitted to edit that column. If you need different transition options for different roles, the recommended approach is to build two separate table configurations: one for Shop Managers with a restricted Allowed Values list, and one for Administrators with the full list. Embed each on a role-restricted page using the allowed_user_roles shortcode attribute to control which users see which version.

WooCommerce core does not enforce status transition validation server-side. Any slug passed to $order->update_status() is accepted as long as it is a registered status. The Allowed Values setting is a TableCrafter UI guard that controls what the frontend dropdown presents, not a server-side transition validator. Custom order statuses registered by third-party plugins (such as those from WooCommerce Subscriptions or shipping carriers) are automatically available as additional slugs you can add to the Allowed Values list.

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.

Audit log considerations

WooCommerce records status changes in the order notes for each order. When TableCrafter updates a status via $order->update_status(), it passes the note text Status updated via TableCrafter inline edit. as the second argument, which is what appears in the order's activity log in WooCommerce admin. WooCommerce also adds its own automatic transition note alongside it. Both entries appear in the same order notes panel, but neither records which WordPress user initiated the change from the frontend table: a Shop Manager changing status through TableCrafter looks identical in the order notes to an Administrator changing status from the WooCommerce order detail screen.

If you need full user attribution per status change, enable TableCrafter's Edit Log feature in Settings → Audit. This writes a separate log entry for every inline edit, recording the WordPress user ID, display name, timestamp, table ID, row ID (the WooCommerce order ID in this context), the field that changed, the previous value, and the new value. The Edit Log is stored separately from WooCommerce order notes and is accessible from the TableCrafter admin panel. For operations where you need to answer "which staff member changed this order status and when", the Edit Log is the correct tool, not the WooCommerce order notes alone.

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.

How Do Caveats and Limitations Work?

• Inline editing only supports order_status by default. Fields like order_total, billing_email, and shipping address require a separate configuration and may not write back correctly depending on WooCommerce's internal validation.
• Changing status on a subscription order (WooCommerce Subscriptions) from the TableCrafter table follows the same path as a regular order. Test this in staging if you have active subscriptions before enabling inline edit in production.
• If you use WooCommerce Blocks for checkout, the status update path is identical, blocks do not change how order status is stored or updated server-side.

TableCrafter's WooCommerce data source requires WooCommerce to be active. If WooCommerce is deactivated after the table is built, the table returns a source configuration error on the next page load. Inline edits are also permission-gated server-side: even if a user crafts a direct AJAX request, the save handler checks the submitting user's role against the column's minimum edit role setting and rejects unauthorized requests before calling $order->update_status(). Logged-out visitors and Customer-role users cannot trigger status changes regardless of how the table is embedded.

For stores where multiple staff members manage orders concurrently, note that TableCrafter does not implement row-level optimistic locking. If two Shop Managers update the same order's status from different sessions within the same second, the later save wins with no conflict warning. Use the Edit Log in Settings → Audit alongside inline editing if you need a full per-user, per-change audit trail to detect and reconcile any concurrent overwrites.