Sugar Calendar already records every attendee. Event Ticketing writes each attendee to sc_event_attendees with a status column like complete, pending, or refunded, an order ID in sc_orders, and a check-in flag stored on the attendee row. The default Tickets screen shows those rows as a list per event with the status as a column label and check-in on a separate scanner screen.

SleekView Kanban reads the same sc_event_attendees rows and groups them by the combined order plus check-in state. The board shows Pending, Complete, Checked in, and Refunded as separate columns with a count at the top and a card per attendee. Each card carries the attendee name, the event title, the ticket type, and the order total from sc_orders, so the front of the card is everything the door staff or organiser needs to act on the row.

Dragging writes back to the source. Moving a card from Pending to Complete flips the order status and triggers the configured Sugar Calendar email, moving a card to Checked in writes the check-in flag and the timestamp on the attendee row, and moving a card to Refunded reverses the linked order through the same hook the Tickets screen uses. Custom event ticket statuses registered by third party addons appear as their own columns without extra configuration.

Event Ticketing already encodes the workflow: a row arrives in sc_event_attendees with status pending, the payment gateway flips it to complete, the door scan writes the check-in flag, and a refund either reverses the linked sc_orders row or moves the attendee to refunded. The default reading surface is still a per-event list of attendees with status as a column label, and check-in lives on a separate scanner screen, so the organiser switches between three screens to read what is really one workflow. SleekView Kanban reads the same attendee rows and lays them out as columns by state with door-ready cards on each one.

Approving a batch is a group drag from Pending to Complete. Check-in is a drag at the door. Refunds reverse the linked order through the same hook the Tickets screen uses, so the plugin reports, the orders screen, and the board all read the same state on the same row.

Custom statuses from third party event addons appear as their own columns without code changes, so a Sugar Calendar setup that adds a wait list or a confirmed-then-attended split stays on the same board the rest of the team already uses.