Event Espresso 4 splits its work across Events, Registrations, Transactions, and Attendees. Each list is a sensible admin screen on its own, but answering the question "how is the event business doing this month" needs all four read together. The data is structured (dedicated tables for events, registrations, and transactions, joined by event ID and registration ID), yet the admin still keeps them in separate tabs.

SleekView reads the EE4 tables directly and joins them so a single grid carries registration status, ticket type, transaction total, and the event name on the same row. Saved views split the work by status, by event, or by date range, and inline edits run through EE4's APIs where supported so status changes still fire the right hooks.

The grid does not change how EE4 processes registrations or charges cards. Approvals, refunds, and ticket assignments continue to run through Event Espresso. SleekView reads the rows the plugin already writes and turns them into the cross-table view EE4 does not ship by default.

Event Espresso 4 has shipped one of the most complete event registration stacks on WordPress for over a decade, and its admin reflects that: dedicated tabs for events, registrations, transactions, and attendees, each with its own filters and bulk actions. The completeness is exactly why a cross-table grid matters. The data lives in well-structured tables, but four separate lists is the wrong shape for the role that owns the event business across them.

Treating registrations as rows with the event, ticket, status, and transaction total joined inline turns the admin from a click-through workflow into a planning and triage surface. Saved views become the rituals of the role (Monday pending-payment sweep, Friday cancellation review, daily approval pass), and the team spends less time toggling tabs to discover what was already structured across the tables.