No. PMPro's Reports keep working and remain the right place for the canonical rollups. SleekView Charts adds a free-form dashboard layer that reads the same tables, so the team can build the non-canonical charts the operational workflow actually needs.

Yes. Each card targets one source, and the canvas holds cards from any source side by side. A typical layout has revenue cards from pmpro_membership_orders, distribution cards from pmpro_memberships_users, and level metadata from pmpro_membership_levels.

Yes. Multiple memberships are rows in pmpro_memberships_users with the same user_id across rows. Chart groupings can either treat each membership independently or group by user_id, depending on whether the chart measures memberships or distinct members.

Recurring orders share a subscription_transaction_id in pmpro_membership_orders. Group by that field to count renewals per subscription, or filter to recurring orders only and chart count per day for the renewal trend.

Yes. pmpro_discount_codes_uses records every code redemption, joinable to the order it applied to. A Bar card ranks codes by total uses or summed revenue impact, which surfaces which codes drove real signups versus which were redeemed once and forgotten.

Yes. Chart aggregations use the same indexed columns as the Table view, so even an order history with hundreds of thousands of rows aggregates in under a second for typical groupings. Cached aggregation results back repeated reloads when the layout is saved.

Yes. Drill-through opens the matching filtered Table view, preserving any dashboard-level filters. A level Donut segment opens a Table filtered to that membership level; an order Area band opens a Table filtered to that date range.

Yes. Each saved dashboard is gated by capability, so finance loads the revenue layout, admins load the membership-health layout, and support loads a single-member context layout. The data sources are shared; the chart layout differs.