Ninja Forms 3.x chose a post-based model for submissions to inherit WordPress capabilities, revisions, taxonomies, and the post APIs. The trade-off is that per-field values live in long-format postmeta rather than dedicated columns. SleekView's pivot makes the long-format data readable as a flat dashboard.

Ninja stores form field definitions as their own posts. SleekView reads those posts to build a mapping from _field_<id> keys to readable field labels. The mapping happens automatically; you don't maintain a dictionary by hand.

Yes for low-cardinality field types (dropdowns, status, radios). The pivot runs at query time, so newly added fields are chartable immediately. Free-text fields produce too many distinct values to chart usefully and are better left to the table view.

Yes for any add-on writing to the same nf_sub post via postmeta. Stripe payment IDs, MailChimp tags, conditional-logic results, and file-upload references all become pivotable dimensions automatically.

Filters use indexed columns on posts (post_type, post_date) and indexed postmeta joins on _form_id. Card aggregations scope by date range to keep query plans tight; sites with hundreds of thousands of nf_sub rows stay responsive when indexes are healthy.

No. SleekView is a read-only chart layer on top of the same posts and postmeta. The Ninja submissions screen, exports, and add-on integrations all continue to work unchanged. Edits routed through the Table tab use direct postmeta updates with conflict detection.

Yes. Save views and scope them per WordPress role or capability. Marketing gets a per-campaign trend dashboard, form admins get a cross-form audit, moderation gets a spam-only queue. Each view persists per user with shared role-scoped defaults.

Each card exports its aggregated rows as CSV with the group-by labels and aggregate values. Useful for handing marketing the underlying numbers behind a campaign chart or archiving dashboard state at the end of a reporting cycle.