BuddyBoss Zoom keeps its data in dedicated tables. bp_zoom_meeting stores one row per scheduled meeting with host_id, group_id, zoom_meeting_id, start_date, duration, type (scheduled, recurring, instant), and status (started, ended, waiting). bp_zoom_recording holds one row per recorded session keyed back to the meeting row, with file size, download link, and timestamp.

SleekView Charts reads both tables as a regular chart source. Each card picks a column to group by (host, group, meeting type, status, date) and aggregates with Count, Sum, Average, Maximum, or Minimum. Cards refresh against the live tables, so a meeting scheduled five minutes ago appears on the next card refresh without any sync step between WordPress and the Zoom API.

A typical setup combines a Number card for total meetings this week, an Area card for daily scheduling activity, a Pie card for the meeting type split, and a Bar card for the top hosts by meeting count. Community admins stop scrolling the meetings list table and start reading whether the integration is actually pulling its weight inside the community.

Live sessions are the moments a community shows up for itself. The integration plumbs Zoom into the social feed, but the value comes from whether the meetings actually happen on a steady cadence, with the right hosts, in the groups that need them. BuddyBoss Zoom stores all of that in bp_zoom_meeting and bp_zoom_recording, but the default admin shows a list table sorted by start date.

Community managers either scroll for hours or export rows weekly, which never happens consistently enough to inform decisions. SleekView Charts reads the same tables, joins them to standard WordPress and BuddyPress relations, and renders Number, Pie, Bar, and Area cards on one dashboard refreshed against the live data. The team finally sees the cadence, the load distribution, and the type split, and the live-session feature stops being a guess and starts being something they can actively manage.