Event Espresso 4 keeps every registration in esp_registration, joined to esp_attendee for the attendee name and email, to esp_ticket for the ticket purchased, and to esp_transaction for the order total. The registration status lives in the STS_ID column which links to esp_status with codes like RAP (Approved), RPP (Pending Payment), RCN (Cancelled), RNA (Not Approved), RDC (Declined), and RWL (Wait List). The default Registrations admin screen is a list table grouped by event.

SleekView reads esp_registration and joins the attendee, ticket, and transaction tables in one query. Flip the view to Kanban and pick STS_ID as the group column. SleekView resolves the IDs against esp_status and labels the columns with the human-readable statuses (Pending Payment, Approved, Not Approved, Cancelled), then renders one card per registration with the attendee name, the ticket, and the transaction total on the front.

Drag a registration from Pending Payment to Approved and SleekView updates the STS_ID through the Event Espresso 4 EE_Registration model so the standard registration-status hooks fire, the registration question groups update, and any registration emails configured for that status transition send the same way they would from the admin screen. Wait List support is included as a fifth column when your event uses it.

Every Event Espresso 4 registration has a status, and every change of status is a decision the team makes. The default admin presents those decisions as rows in a list and a dropdown in the registration edit screen. That works for a single seat, but it falls apart on event day.

Box office needs Pending Payment in front of them, finance needs Approved and Cancelled side by side, and the wait-list coordinator needs the wait list visibly next to live seats. SleekView reads esp_registration, joins the attendee, ticket, and transaction tables, and groups by STS_ID with human labels so the team finally sees the same data as a real ticketing pipeline. Dragging a card calls the EE_Registration model, which fires the same registration-status hooks the admin uses, so emails, capacity, and revenue totals update on every move without any custom glue code.