Wishlist Member X (the X-line release of WishList Member) keeps its operational data in custom tables prefixed wp_wlm_. Per-user level assignments live in wp_wlm_userlevels with the user_id, level_id, status, expiry date, and the registration date. Transactions land in wp_wlm_transactions with the gateway, parent subscription, status, and amount. Level definitions sit in their own table with the human-readable name and the access rules referenced by member-level joins.

The default Wishlist Member admin shows per-user profiles and a separate Levels tab. Bulk questions like "every member on the Pro level whose expiry date is in the next 14 days" or "every cancelled member still attached to a paid level" need exports or per-user clicks. The reporting module covers totals but not the row-level cohort views ops actually needs for renewals and cleanup.

SleekView reads wp_wlm_userlevels directly, joins wp_users for contact email, joins the level-definition table for the level name, and joins wp_wlm_transactions for last-charge state. The result is a single member-level table where expiry, level, lifetime spend, and last charge are first-class columns. Filters combine level, expiry window, and last-charge status to make renewal and cleanup audits one saved view.

Wishlist Member's strength is per-member level control, and its weakness is that the default admin asks ops to think one member at a time. Renewal outreach is a cohort question: every Pro member expiring in the next 14 days. Cleanup is also a cohort question: every cancelled member still attached to a paid level.

The plugin stores the data to answer both, but in two tables behind two screens with reports in a third. SleekView's joined view turns those cohort questions into single screens where expiry, level, and last-charge status are columns. Renewal ops can run a fortnightly outreach pass from one view; finance can audit the dunning queue from another; support can see the full per-member picture without leaving the chat.

For installs running Wishlist Member's content-protection rules, the workspace exposes the protection definitions as a parallel view so admins can audit access without per-rule clicks. The tables stay authoritative; the workspace just makes them legible at scale.