WP Event Manager already encodes a real workflow. Event listings live in the event_listing custom post type with a post_status of publish, pending, or expired, plus a featured flag and expiry date. The registrations addon adds attendee rows in event_registration with statuses like approved, pending, or cancelled. The default Events screen shows listings as a table sorted by date and registrations live on a separate per-event screen.

SleekView Kanban reads both data sets and groups them on dedicated boards. The Listings board has Pending review, Published, Expiring soon, and Expired as columns so the moderator works approvals as a queue. The Registrations board has Pending, Approved, Cancelled, and Attended as columns, with one card per registration row carrying attendee name, event title, ticket variation, and registration total when ticketing is wired in.

Dragging writes back to the source row. Moving a listing from Pending review to Published flips post_status to publish and triggers the configured WP Event Manager email, moving a registration to Approved sends the approval email, and moving a registration to Cancelled either reverses the linked Woo order through the ticketing addon or simply flips the status when there is no order. Expiry dates appear as a flag on the card so the moderator handles renewals before they hit the Expired column.

WP Event Manager runs two related workflows on the same site. Listings come in from the frontend submission form as pending review and need a moderator to flip them to publish, set expiry, and decide what gets featured. Registrations come in from the registrations addon as pending and need an organiser to approve, watch, and reconcile with check-in.

The default reading surface mixes both into screens designed for a single-event admin: a Listings table with status as a column label and a per-event registrations screen behind a row click. Running a directory of more than a handful of events means scrolling through the listings screen for moderation and then opening each event to work its registrations. SleekView Kanban splits the two into purpose-built boards.

The Listings board reads from event_listing with Pending review, Published, Expiring soon, and Expired columns and an expiry flag on cards, so the moderator works approvals and renewals as a queue. The Registrations board reads from event_registration on the same boards as ticketing, with Pending, Approved, Attended, and Cancelled as columns and the linked Woo order handled by the drop. The plugin reports keep working because SleekView writes to the same source rows.