Yes. Survey field types and the polls renderer ship with the Surveys and Polls add-on, which is gated behind a Pro license. SleekView reads the entries the add-on writes, so without it there's no survey data to display.

Yes for the field types WPForms' admin API supports (text, single-choice, multi-choice, rating). The standard wpforms_process_entry_save hook fires so any downstream automation runs normally. Direct DB writes with conflict detection cover edge cases.

Multi-choice fields store one row per selected option in wpforms_entry_fields. SleekView aggregates them into a single readable cell with the selected labels, and filters treat each option as a value, so "contains Pricing" works without scripting.

Yes. Add the rating column and the linked open-text column side by side. Both are pivoted from wpforms_entry_fields, so detractor context appears on the same row as the score, ready for triage.

If a survey runs without capturing email, that column simply stays empty. SleekView never invents identity. Filter on has email to scope a campaign list, or leave it open for aggregate analysis.

The pivot runs at query time with indexed joins on entry_id and field_id. For very wide column sets, scope the column chooser to a recent date range so meta-key discovery stays responsive. Saved views run paginated and use only the columns shown.

Yes. Exports honour the current filter and column selection, so the CSV mirrors the table on screen, not the raw long-format storage. That's the difference that makes spreadsheet handoffs usable downstream.

No. The chart screen is good for at-a-glance summaries. SleekView is the next layer down, the operational table that answers "which respondents, in what window, with what other answers?" The two complement each other.