By default SleekView groups by the ticket_status taxonomy because that is the field every Awesome Support agent already triages around. You can also group by ticket_priority for triage shifts, or by the _wpas_assignee meta for per-agent swimlanes.

Yes. SleekView writes through Awesome Support's CRUD layer so wpas_after_close_ticket, the agent-assignment hook, and the email-reply triggers all fire exactly as if an agent had used the ticket edit screen, including the change appearing in the ticket history.

Yes. Any field on wpas_ticket including postmeta values and taxonomy terms can be added to the card front. Numeric fields render as badges, dates as relative time, and longer strings truncate so cards stay scannable across three or four columns.

Because SleekView calls the same CRUD layer Awesome Support's own UI uses, SLA timers, reminder schedules, and automation rules behave identically. A drag from New to Processing resets the response-time clock the same way the dropdown change would.

Yes. Each board is a saved view stored per user or shared per role, with its own columns, filters, card fields, and color palette. The billing lead loads the billing board, the escalation manager loads the urgent-only board, and the data underneath is shared.

Yes. Kanban, Table, and Charts views are three render surfaces over the same wpas_ticket dataset. Switching between them is one click in the SleekView header, and the existing All Tickets screen continues to work for users who prefer the list.

Yes. Filters compose on top of the kanban grouping, so a board can show only tickets in the billing channel, only High and Urgent priority, or only tickets assigned to a specific agent. The filter applies to every column in view.

SleekView polls for new tickets at a configurable interval, defaulting to thirty seconds. New rows appear in the New column with a brief highlight, and the column count updates so the lead notices a backlog growing before the next manual refresh.