Connections Business Directory stores entries in wp_connections as the master record, with related data normalized across wp_connections_address, wp_connections_phone, wp_connections_email, wp_connections_link, and wp_connections_date. That schema is great for one-to-many cardinality (multiple phones per business, multiple addresses per non-profit) but the default admin list is one row per entry with only name, organisation, and date visible.

SleekView joins those related tables back to wp_connections on entry_id at query time. Primary phone, primary email, primary address, and any registered metabox field promote to named columns. Categories from wp_connections_terms attach as filterable taxonomy joins. The entry type column (individual, organisation, family) becomes a first-class filter so contact-style and business-style entries can be scoped per view.

The grid matches how directory ops actually work. Filter to entries with no email but a website, sort by category and last-modified date, bulk-toggle visibility on a moderation pass, and inline-edit organisation, primary phone, or category from the row. Writes route through Connections' own CRUD layer so the related tables update consistently and the plugin's cache invalidation fires on every change.

Connections Business Directory's data model is exactly right for the kind of directories it serves: staff lists, membership rosters, business directories with many contact points per entry. Splitting addresses, phones, and emails into their own related tables is the correct way to model that cardinality. The cost is that the default admin list shows one row per entry with almost none of the related data visible, because joining five tables at render time is exactly what a generic posts list cannot do.

SleekView solves that join at query time so primary phone, primary email, primary address, and any registered metabox field promote to named columns. Filters cover entry type, category, and visibility in one saved view, and inline edits route through Connections' own CRUD so the related tables stay consistent and cache invalidation fires on every change. The directory editor finally sees what the schema already holds, and bulk approvals or category updates stop being a per-row editor ritual.