Yes. SleekView reads wc_orders, wc_order_addresses, wc_order_operational_data, and wc_orders_meta when HPOS is enabled — the default since WooCommerce 8.2. On legacy stores it transparently switches to the shop_order post type and postmeta, so the same SleekView config works across both schemas without rewriting columns.

Yes. SleekView lets you add columns sourced from wc_orders_meta on HPOS or postmeta on legacy. The agent UI scans your installation and lists meta keys actually in use, so you pick from a real list instead of guessing names — useful when third-party plugins add tracking, fraud, or gift-message keys.

Yes. SleekView writes through WooCommerce's CRUD layer where supported, so woocommerce_order_status_changed, woocommerce_payment_complete, email triggers, inventory updates, and webhook deliveries all fire as expected. Bulk operations don't bypass these — they iterate through CRUD so the side effects are identical to manual edits.

Each table is one view, but views are switchable inside a single SleekView page. Build a tabbed setup with one tab per source — Orders from wc_orders, Products from the product post type, Customers from wc_customer_lookup. Or use a kanban view of orders grouped by status alongside the table.

WooCommerce Subscriptions stores subscriptions as the shop_subscription post type and, in recent versions, optional custom tables. SleekView reads the post type out of the box; the custom-table support depends on your Subscriptions version. Joining subscriptions to parent orders in one view is supported either way through the post-parent relationship.

No — it's an additional admin surface. Default WooCommerce screens stay where they are for merchants who like them. SleekView gives ops, finance, and support teams the row-level views they actually need without disturbing the merchant admin or rewriting workflows that already work.

Queries hit indexed columns (id, status, date_created_gmt, customer_id) directly on wc_orders, which is why HPOS exists. Filters and sorts use those indexes; pagination is keyset where possible. Aggregate columns (lifetime value, item counts) are opt-in per view since they're heavier — keep them off the default list and on per-customer detail views.

Yes. Refunds are stored as child orders with shop_order_refund type on legacy and a parent-id link on HPOS — SleekView can either show them inline as a related table per order or as their own view scoped to a date range. Order notes are exposed through the comments table joined on comment_post_ID, useful for support audit trails.