No — Ninja Forms 3.x stores submissions as nf_sub custom posts. Per-field values live in postmeta as _field_<id> rows, with the form ID as _form_id. SleekView reads both and pivots them into a tabular view. This post-based design is unusual for a major forms plugin but inherits WordPress capabilities and revisions for free.

Yes — SleekView writes back to postmeta with conflict detection and audit logging. Each change records who made it, when, and the previous value, so admins can trace edits during reviews. Bulk edits run as a transaction and roll back per-row on conflict, leaving the rest of the bulk operation intact.

SleekView reads the form's field definitions (Ninja stores these as posts of their own) to map _field_<id> keys to human-readable labels. The mapping happens automatically — you don't maintain a column-key dictionary by hand. New fields added to a form become available columns the next time the column picker opens.

Yes for any add-on storing extra data on the nf_sub post via postmeta. Stripe, PayPal, MailChimp, file uploads, conditional-logic results — all surface as additional pivotable columns. Add-ons that write to their own custom tables can be exposed via separate SleekView views joinable to the entry by post id.

Ninja Forms exports work as before — SleekView is read/edit only and doesn't touch how Ninja exports CSV or JSON. You can use SleekView to filter to the exact rows you want exported, then run Ninja's standard export on that filtered set, or use SleekView's own CSV/JSON export which respects the column choice in the view.

Yes — deleting a submission row in SleekView trashes the nf_sub post (and its postmeta) via the standard WordPress delete pipeline. Same behaviour as the default admin. Restore from trash works the same way too. Bulk deletes iterate per row so any deletion hooks add-ons register run as expected.

SleekView's CSV export gives you the full pivoted submission set in a clean tabular format, which is the right starting point for migration into Gravity, Fluent, or WPForms. SleekView itself isn't a migration tool — there's no automated import to another plugin's schema — but the pivoted export saves the manual work of unwrapping postmeta before you feed it into a target plugin's importer.

Filters use indexed columns on posts (post_type, post_date, post_status) and indexed postmeta joins on _form_id. Pagination is keyset by post id where possible. The pivot itself is the heavy part on huge datasets — limit pivoted columns to the ones the view actually shows rather than pulling every _field_*, and scope by date range to keep query plans tight.