The Teachable for WordPress integration mirrors Teachable enrolment and access state locally as user meta keys (teachable_user_id, teachable_courses, teachable_last_sync) on wp_users, with a per-site sync registry stored in wp_options and (depending on add-on configuration) per-course access tokens kept in wp_postmeta on the linked WP course posts. The default integration settings page is configuration-only: connect API key, configure mappings, save.

Operational questions like 'which users are connected to Teachable and which are not', 'which Teachable courses are mapped to WP pages and which are orphaned', 'when did each user last sync and which syncs are stale' don't have a built-in screen. They're answered today by checking the Teachable dashboard for one user, then opening the WP profile for the same user, then comparing.

SleekView reads the local mirror tables directly. A connection-status view joins wp_users with teachable_user_id meta to show which users have Teachable accounts paired and which don't. A course-mapping view lists WP course posts and the teachable_course_id meta they carry, flagging orphans and duplicates. A sync-health view sorts users by teachable_last_sync so stale rows surface at the top. Re-sync actions route through the integration's API so its retry and throttling behaviour applies unchanged.

Teachable for WordPress works hard to keep the WP and Teachable sides in sync, and most of the time it succeeds quietly. The challenge is the part that lives between those two systems: which users are paired, which mappings are stale, which course assignments drifted between sync runs. The default integration screen handles the connection setup beautifully and then assumes the operational layer is someone else's problem.

In practice the operational layer is a daily reality for admins running paid-content sites: members complain about missing course access, support reps need to confirm pairing status during chat, marketing teams want to segment by who's engaged inside Teachable. None of those questions are SQL questions; they're saved-view questions against tables the integration already writes to (teachable_* usermeta, course-mapping postmeta, the sync-registry option). SleekView's job is to expose those tables as filterable views, route re-sync actions through the integration's own API so behaviour stays consistent, and let each role build the view their job actually needs.

Same data, hooks fire when wanted, dramatically less time spent in the Teachable dashboard cross-referencing one user at a time.