WP Job Manager doesn't ship with custom database tables. Listings live in wp_posts as the job_listing CPT, and the fields that drive moderation work, _job_location, _company_name, _job_expires, _featured, _filled, and _application, sit in wp_postmeta as long-format rows. The default WordPress posts list cannot surface those columns, so the admin defaults to title, author, and date.

SleekView reads job_listing, joins postmeta back at query time, and exposes each key as a first-class column. The Resume Manager and Applications add-ons follow the same shape: resume and job_application CPTs with their own meta keys (_candidate_email, _job_id). One saved view can span all three when teams need to triage roles, applicants, and resumes together.

Edits route through the standard WP post APIs, so toggling _featured, pushing _job_expires forward, or flipping _filled on a closed role still fires every action and filter the plugin and its add-ons register. Bulk operations and saved per-role views finally make the listings admin scale with the board.

WP Job Manager exists to manage listings at scale, but its default screens hide the fields that decide which listing you act on next. Featured is buried, expiry sits behind a row click, and application count is another navigation away. On a board with even fifty active roles, that means dozens of round trips a day just to figure out which listing needs attention.

Multiply that across moderators, employers, and a Resume Manager queue, and the admin becomes the bottleneck. The data is already there, every value lives in wp_postmeta, but WordPress' generic posts list cannot surface it without custom code. SleekView's pivot turns the moderation queue into a real workspace where the columns you sort and filter on are the ones board operators actually use.

Bulk-toggling featured on twenty roles, expiring stale postings overnight, or letting an employer manage their own slice via a capability-gated view stop being engineering tasks and become a single saved view.