AcademyPress structures online learning as courses, lessons and learner enrolments on top of WordPress. Course content lives in custom post types, learner progress is stored as usermeta keyed by user_id with lesson and course completion flags, and enrolment records connect users to courses with date stamps. The plugin surfaces this through per-course screens and per-learner profiles, which is right for editing a syllabus and wrong for auditing the cohort.

SleekView reads the AcademyPress course posts joined with learner usermeta and renders each enrolment as a row. Filter to last-30-days sign-ups for launch reviews, sort by status to find stalled learners, group by course_id to see catalogue distribution. The same dataset the chart view aggregates becomes a row-level surface for academy admins, instructors and support.

The plugin keeps owning course delivery, lesson gating and certificates. The table view owns the audit surface, so the enrolments AcademyPress already writes stop hiding inside per-profile panels and become something academy operations can actually query.

AcademyPress already captures the data an operator needs: who enrolled, in which course, on what date, with what status. The default surface places that data inside per-course and per-learner screens, which is right for editing a syllabus and unhelpful for almost everything operators do at the cohort level. A queryable table of enrolments answers questions instructors actually ask: who has stalled, who finished last week, which cohort needs the next nudge.

Same usermeta rows, completely different decision posture. The table renders the academy AcademyPress already runs as an auditable cohort, which is the difference between knowing the courses exist and knowing exactly where every learner stands this week.