WooCommerce Multistore extensions in the WooMultistore and Aelia families push products, stock levels, prices, and orders between a master store and one or more child stores. Each sync becomes a row in the plugin's job queue, usually in a table like wp_wms_sync_queue or driven by Action Scheduler, with a status column that moves from pending to syncing, then to completed or failed. Child-store orders that flow back to the master land in wc_orders with the origin store recorded in wc_orders_meta.

SleekView reads the sync queue table and joins on the child-store registry so each job carries the source store, the target store, the object type (product, order, stock), and the affected ID. The natural column to group by is status, which moves through pending, syncing, completed, and failed on every job. Cards show the object type, the source and target store names, the affected ID, and the duration calculated from the start and finish timestamps.

Dragging a card from Failed back to Pending writes the new status value to the sync queue row, which is what the plugin's own retry action does. The scheduler picks the job up on the next tick and re-runs the push using the same configuration that produced the failure. The same board can be cloned for the master-store wc_orders table with a filter on the origin store meta so child-store orders show up as their own pipeline grouped by the standard WooCommerce statuses.

Multistore networks fall over quietly: a child store's API key rotates, a price rule rejects an update, a timeout pile-up turns one slow target into hundreds of failed jobs. The default log screen lists everything in time order with a status filter, which means ops only spots the problem once a downstream customer complains. A kanban grouped by status puts the queue's shape on one screen.

Pending, Syncing, Completed, and Failed become columns, counts on each column show backpressure live, and each card carries the source store, the target store, the object type, and the duration. Dragging a card from Failed to Pending writes the new status to the queue row, which is what the plugin's retry action does, so the scheduler picks the job up on the next tick. A second board filtered to child-store orders by their origin meta gives master-store finance the same kanban for the sales the network produced, grouped by the standard WooCommerce statuses.

The team works the same data the log works, just with position and counts doing the heavy lifting.