Yes for entry storage. WPForms Lite doesn't store submissions in the database — entries go to email only — so there's no source data for SleekView to display. Pro creates wpforms_entries, wpforms_entry_fields, and wpforms_payments on activation. SleekView detects the tables and the column picker lights up automatically once they exist.

Yes. SleekView uses WPForms' admin APIs where available, which respects field validation and fires the standard hooks. For field types the API doesn't fully expose, SleekView falls back to direct DB writes with conflict detection — the row is re-fetched on save and warns if it changed since you opened the cell.

Yes — payment data lands in wpforms_payments regardless of gateway, with gateway as a column. SleekView's payment views work the same across all supported gateways. Filter by gateway for per-processor reconciliation, or leave it open for a unified view of all payment activity across the site.

Yes. wpforms_entry_meta rows are exposed as filterable fields, in addition to the pivoted entry-field columns. Add-ons that write to entry-meta (UTM tracking, custom integrations, conditional-logic results) become filter options without per-add-on configuration. The filter UI lists meta keys actually present in your installation.

SleekView is a read/edit layer, not a sync. If an entry is deleted via WPForms or directly in the database, it disappears from SleekView automatically on the next refresh — there's no cached copy to clean up. Bulk-delete from a SleekView row routes through the WPForms admin API so the standard deletion hooks fire, including any cleanup logic add-ons register.

Yes. Save named views and scope them per WordPress role or capability — sales sees a cross-form unread inbox, finance sees the payments-joined view, moderation sees spam-only. Views are config artefacts, so they're versionable in your codebase if you want them under git rather than re-created in each environment.

WPForms writes spam decisions to the entry's status column and to wpforms_entry_meta with details on why. SleekView surfaces both — filter to spam-flagged entries with the reason as a column to spot patterns (specific IPs, specific form fields, specific times of day). Useful for tuning anti-spam settings or reporting abusers without scripting against the database.

WPForms' Form Abandonment add-on stores partials as regular entries with a partial status, not in a separate table. So they show up in the same SleekView with status as a column. Filter to partials only for an abandoned-form recovery workflow, or exclude them from the sales triage view so reps see completed leads only.