Yes. SleekView reads from any Course Builder table that ships with a vote counter and a status column, including cbwp_requests, cbwp_attempts, and the optional cbwp_certificate and cbwp_grades tables added by the paid modules. New tables show up in the data source picker the next time the plugin is upgraded.

They do. The Course Builder mobile reader increments the vote counter through the same REST endpoint the desktop site uses. SleekView Feedback reads from that exact counter column, so a tap in the mobile reader shows up on the board on the next render and counts toward the sort order without any mobile-specific config.

Yes. The data source picker lets you filter the underlying query by course ID, lesson ID, tag value, or any meta field stored on the request row. A single course, a single lesson, or a curated set of high-signal lesson requests can each get a dedicated SleekView board on its own WordPress page for the right student audience.

Status pill changes update the Course Builder request status column you mapped to the status field. That is the only write. The original request body, vote counter, and student identity stay untouched, so instructors can revert a status by editing the column and any audit log plugin watching the builder tables sees the change.

Rejected requests and hidden quiz attempts drop off the board because SleekView queries only visible rows by default. If you want a moderator view that includes pending, hidden, or rejected rows, the query filter accepts a status array, so instructors can triage them without exposing the rows to enrolled students on the public page.

No. SleekView paginates the underlying query, caches the sorted set per page slug, and only fetches the rows it needs for the current page. A board over fifty thousand Course Builder requests serves in the same time as a board with five hundred because the database does the heavy lifting once and the cache covers every subsequent visitor.

Yes. The board reads from the Course Builder tables independently of enrollment, so a public roadmap page can show lesson requests, votes, and statuses to prospective students. Voting itself can be gated to enrolled students by checking the standard Course Builder enrollment meta on the submit handler on the page.

The board keeps rendering as long as the cbwp tables exist in the database. Deactivating the plugin freezes the data at the last write, so the board still serves with stale counts until reactivation. Migrating to a different LMS drops the tables and SleekView falls back to a clear empty state instead of erroring on the page.