FluentCRM Affiliate (the Fluent Affiliate module wired into FluentCRM) tracks partners, referrals, visits and payouts across its own tables (fct_affiliates, fct_affiliate_referrals, fct_affiliate_payouts and related), with status flags for pending, approved, paid and rejected referrals plus per-affiliate aggregates for total earnings and unpaid earnings. The default admin gives one screen per table, which works for individual lookups and breaks the moment a program manager wants to see partner, referral status and unpaid balance in one filtered cohort.

SleekView reads those tables together and exposes affiliate_id, referral_id, status, amount, type, contact_id, created_at and payout fields as one queryable dataset. A referrals view shows partner name, status, amount, type and created_at in the same row, sortable by any column and filterable in combinations the default admin does not surface. A payout queue view filters to approved-but-unpaid referrals, sums the amount column for the next cycle and lets a payout admin bulk-mark them paid after the actual transfer runs.

Inline status edits route through the FluentCRM Affiliate CRUD layer where supported, so approved, paid and rejected status changes trigger the same hooks the default UI fires. Downstream FluentCRM automations on referral status changes (contact tagging, email sequences) keep working without extra wiring.

FluentCRM Affiliate already records the full partner lifecycle: who referred whom, which referrals converted, which got paid and which got rejected. The default admin shows each piece on its own screen, which works for individual lookups and breaks for almost every decision a program manager makes at the cohort level. A table that joins partners, referrals and payouts turns three screens into one workspace, where filters combine status, partner and date in a single click and bulk-approve or bulk-mark-paid happens in one pass instead of one referral at a time.

Same FluentCRM Affiliate tables, same status flags, completely different operational posture. The table renders the data the plugin already maintains as a queryable, editable surface, which is the difference between running the program off exports and running it off the live source of truth.