No. The feedback custom post type is part of the Jetpack plugin (and works in offline mode without a WordPress.com connection). SleekView reads the CPT directly, so connection state doesn't affect what's visible. Akismet spam checking continues to run as Jetpack configures it.

Yes. The Jetpack Form block stores submissions in the same feedback CPT as the legacy shortcode form. SleekView reads both side by side; you can filter by which form variant was used if that matters for your audit.

SleekView allows editing post-level metadata (status, post date) directly. The encoded form payload itself is preserved as the original submission record, overwriting it would compromise the audit trail. Replies and notes attach as related comments on the feedback post.

Jetpack Forms stores fields in a known encoding inside post content and meta. SleekView parses the encoding (key/value pairs per submission) and exposes the keys as addable columns. Field names come from the form configuration; new fields appear as new columns after the next submission with that field arrives.

Akismet spam-checking still runs as Jetpack configures it, SleekView doesn't bypass or replace the check. Spam-flagged submissions appear with their spam status, which makes them filterable as a separate view ("recently spam-flagged this week") for tuning purposes.

Jetpack added optional payment fields backed by Stripe. The payment status and amount surface in the post meta on submission; SleekView pivots them into columns. Useful for sites that took a payment via a Jetpack form rather than a full WooCommerce flow.

Jetpack CRM is a separate plugin that can ingest Jetpack Forms submissions into its contacts pipeline. SleekView reads the feedback CPT regardless of CRM presence; if CRM is installed, the resulting contacts can be viewed through SleekView's Jetpack CRM integration as a related view.

feedback is a normal post type, so the standard posts/postmeta indexes apply. Date filters and status filters are indexed lookups. Pivoting the encoded payload happens at query time but is bounded by the number of rows in the current page of results, pagination keeps the work small per request.