No. SleekView reads what your WordPress database holds. If you run a sync layer that mirrors Zendesk tickets into a custom WP table, those rows become sortable, filterable, and kanban-able. Without a sync layer, Zendesk tickets stay in the Zendesk app, which is where their Triggers, Macros, and reporting already operate.

Web Widget configuration sits in wp_options. Captured leads from contact forms or pre-chat surveys depend on which integration captures them. Some bridges write to a custom table, some to postmeta, some pipe directly to Zendesk without a WP record. SleekView surfaces whichever path your stack uses without assuming a single schema.

Yes. New, open, pending, on-hold, and solved each become a kanban column when status is the grouping field. Drag a card from open to pending and the row's status field updates through the WP write path; if you've wired a webhook listener back to Zendesk, the cloud side stays in lockstep.

Only if your stack has a webhook listener or API bridge that propagates WP-side changes to Zendesk. SleekView itself edits WordPress data only. Many teams find WP-side edits are enough for the records they sync locally, since Zendesk remains the source of truth for the ticket itself.

Yes. Sorts compose, so primary by priority and secondary by age (oldest first within each priority bucket) is a single saved view. Useful when high-priority stale requests should sit at the top and recently created low-priority ones can wait below.

Yes. Saved views are gated by capability, so support analysts get the active queue, leads get a wider view, and reporting roles get a read-only view of the same source. Inline edits honour the same capability checks, which prevents an analyst from accidentally changing assignee or status from a report.

Yes. Any saved view exports to CSV with the columns and filters you've configured, regardless of whether the layout is a table or a kanban. Useful for handing data to a non-WP stakeholder, monthly reporting, or pulling Zendesk-adjacent data into a spreadsheet for ad-hoc analysis.

The Zendesk WP integration has had several iterations over the years; SleekView doesn't depend on a specific plugin version. It reads the WP database directly, so whatever options, custom tables, or postmeta the active integration writes is what SleekView surfaces. If the integration changes its schema, you re-pick the source columns from the agent UI.