Ultimate Member Friends keeps the social-graph data in custom tables under the um_friends_ prefix: um_friends for accepted connections with user_id, friend_id, and connected_at, plus a request-state table for pending and rejected requests with status and requested_at. The default admin lists a member's friends on the profile, but offers no community-wide graph view.

SleekView Charts reads the same tables and exposes them as a social-health dashboard. A Number card counts total accepted connections. A Pie splits requests by status (accepted, pending, rejected). A Bar ranks top connectors by friend count. An Area plots connection volume per day so the dashboard shows whether the community is forming new ties or stagnating.

Every card runs against the live um_friends_* tables, so a connection accepted minutes ago appears in the total count and the top-connector Bar at the next refresh. Community managers gate a growth dashboard, moderators get a pending-request workload view, all from the same source the friend-list profile screen reads.

Friend graphs are the value layer most community plugins try to build, but few make the data observable. UM Friends stores every connection, request, and rejection in dedicated tables, then exposes it as a per-profile friend list and nothing else. Community managers who want to know whether the graph is growing, whether onboarding drives connections, whether one account is suspiciously over-connected, end up running custom queries or trusting gut feel.

SleekView Charts runs against the same um_friends tables the profile screens read, so the connection count, the top-connector Bar, and the daily velocity Area all stay in lockstep with the live graph. One source, one dashboard, all from the WP admin without writing SQL.