AutomateWoo stores every workflow run in the wp_automatewoo_queue table. Each row carries a workflow_id linking back to the aw_workflow post type, a status column with values like pending, processing, complete, failed, and cancelled, a date_created timestamp, and a date_run for when the run is scheduled to fire. The plugin's queue screen lists everything in one long sortable table, which is fine for debugging a single run but offers no overview of the whole automation backlog.

SleekView Kanban reads the same wp_automatewoo_queue rows you would query with AW_Queue. Pick status as the group column and every queued run becomes a card slotted under Pending, Processing, Completed, or Failed. Card fronts show the workflow title from aw_workflow, the customer or order ID the run is targeting, the scheduled date_run, and a short reason from the failure log, so an ops engineer triaging a backlog spike sees which workflow is misbehaving without opening a single edit screen.

Dragging a card from Failed back to Pending runs the same queue helper the admin retry button uses, which fires automatewoo_queue_item_status_changed. The run gets rescheduled into the worker, any rate limit counters reset, and the workflow's variable replacements rehydrate from the order or customer, exactly as they would after a manual retry from the queue screen.

Stores running AutomateWoo accumulate tens of thousands of queue rows every month. Some are abandoned cart reminders scheduled for tomorrow, some are review requests waiting on a delivery date, and a steady trickle are runs that failed for reasons nobody has triaged yet. The default queue screen treats them all the same, which means ops engineers end up running SQL or exporting CSVs every time they need to find out why Friday's review requests did not send.

The disconnect between what the worker actually processes and what the team can see shows up in the worst places. A marketing manager launches a new welcome series and only learns it is broken when the support inbox fills with complaints two days later. A retention engineer pushes a cart recovery experiment and cannot tell whether the spike in Failed runs is a code issue or a deliverability issue.

A kanban view that reads and writes the same wp_automatewoo_queue rows the worker reads keeps the team and the queue honest. Every drag is a real status change, every column count reflects the real backlog, and the cards themselves carry enough context for an on-call engineer to triage at 3am.