No. SleekView reads the job_application custom post type and its postmeta in place. Nothing is copied or synced, every chart query runs against the live wp_posts and wp_postmeta tables, so the numbers always match what the Applications plugin shows on its own screens.

Any post_status registered via the job_application_statuses filter shows up automatically. If you add screening, technical_interview, reference_check or any other stage, group-by post_status picks them up the next time the chart is viewed, no chart edits needed.

Yes. Group by post_author if you assign recruiters via authorship, or by any postmeta key you write like _assigned_recruiter_id. SleekView resolves the user ID to a display name in the chart legend so the result is readable.

Yes, as long as applications are stored as the job_application post type with the standard meta keys. Customized forks (like Pressed Solutions' Customized Applications) still write to job_application, so the same charts work without modification.

SleekView uses indexed wp_postmeta joins and caches aggregated results per chart. A site we tested with 47,000 job_application rows across 4 years rendered the full four-card dashboard in under 600ms once the cache warmed up.

Yes. Filter by the parent job_listing post ID through _job_applied_for, or by the job_listing_category taxonomy attached to that parent job. The chart will only show applications belonging to the filtered jobs.

No. Charts are rendered inside wp-admin behind the manage_options or manage_job_listings capability by default, and aggregations like Count and Sum never expose individual rows. Personally identifiable fields stay where the Applications plugin put them.

Point the groupBy at whatever key you use. SleekView lists every meta key present on the job_application CPT in the chart builder, so if you write source to applicant_source instead of _application_source, just pick that one.