LifterLMS stores quiz attempts in wp_lifterlms_quiz_attempts with one row per attempt and per-question results in wp_lifterlms_quiz_attempt_questions. The Advanced Quizzes add-on layers richer question types and analytics on top of the same schema. The default reporting screens are pre-shaped: per-student score lists, per-quiz averages, and not much else. Anything you want as a different shape (per-question pass rates, slowest grading queues, repeat-attempt patterns) needs custom queries.

SleekView reads the attempt tables directly so instructors and program teams can compose the views their workflows need. A quiz leaderboard sorts attempts by score across courses. A per-question difficulty report aggregates wp_lifterlms_quiz_attempt_questions by question and pass rate to surface ambiguous items. A grading queue filters attempts where manual review is pending, sorted by oldest first.

Inline grade edits route through LifterLMS's quiz APIs where supported so the standard hooks fire and any integrations listening respond normally. Direct-table edits skip hooks by design for back-fill scenarios. Multisite installations get per-subsite scoped views automatically.

Quizzes are the most data-rich part of any course, and they sit at the centre of two questions every program eventually asks. Are learners passing? And are our quiz items actually measuring what we think they are? LifterLMS records everything you need to answer both questions: every attempt, every per-question result, every score. The default reporting screens answer the first question well enough at a glance and the second question barely at all.

Curriculum designers want per-question pass rates to find ambiguous wording. Instructors grading essay answers want a queue sorted by oldest pending, not a per-quiz drill-down. Program leads want to see which courses have strong enrollment but weak quiz performance.

None of those views require new data; they all live in lifterlms_quiz_attempts and lifterlms_quiz_attempt_questions already. SleekView's job is to expose those tables as a composable workspace so each role can build the view their workflow actually demands, with no custom queries and no rebuilt reports.