BuddyPress stores profile data in bp_xprofile_data as one row per field per user, activity in bp_activity with moderation flags, groups in bp_groups and messages in bp_messages_messages. Each table has its own admin surface and its own filters, which is the right structure for the platform and the wrong shape for cohort-level work. Reporting across components requires either custom SQL or repeated per-screen clicks.

SleekView reads the bp_* tables directly, pivots bp_xprofile_data into named columns using bp_xprofile_fields for labels and renders the result as a sortable audit table. Each activity row is one row with member, component, group_id and date_recorded as columns. Filter to moderation flags to triage abuse. Sort by date_recorded for recent activity review. Pivot xprofile fields (country, job title) into columns to combine activity with profile context.

BuddyPress keeps owning notifications, group membership and component logic. The table view owns the audit surface, so the activity, profiles and group rows BuddyPress already writes stop hiding behind per-component screens and become something community managers and moderators can actually query.

BuddyPress is structurally a multi-table community platform: profiles in bp_xprofile_data, activity in bp_activity, groups in bp_groups, messages in bp_messages_messages. That schema is right for the platform and unreadable at the cohort level until you pivot xprofile and join the rest. SleekView reads the same bp_* tables and renders them as a queryable audit table with member, component, group and pivoted xprofile fields as real columns.

Filters stack into a single query so the moderation queue, the cross-group cohort and the profile audit become one-click saved views. BuddyPress keeps owning notifications, group logic and component code, while community managers and moderators get the per-row surface the dataset always deserved.