Yes. SleekView queries formcraft_3_submissions directly and joins formcraft_3_forms on form_id for the readable form name. Submission date and form id columns come from the table directly; field values extract from the serialised blob into named columns on demand.

Per-field values in FormCraft are stored as a serialised blob on the submission row. SleekView reads the row directly for the date and form columns. For specific field values, SleekView extracts individual keys from the blob and exposes them as filterable columns. The non-extracted values stay in the blob, viewable on row expand.

Yes. Extracted field keys become first-class columns and filter like any other. Performance is best when the extracted field is also indexed at the database level (some FormCraft installs add separate indexes for common search fields); otherwise scope by date range to keep filters fast.

FormCraft 2 used a different table name and storage layout. SleekView can be pointed at FormCraft 2's tables, but the field-extraction logic differs because the older schema serialises differently. Most current sites run FormCraft 3, where the patterns described here apply directly.

Yes. SleekView views are gated by WordPress capability, so a client or stakeholder with the right cap reads the table without admin rights. Frontend embedding works for sharing trends with people outside WP Admin.

Yes. The core query hits indexed columns on form_id and submission_date. Field extraction is bounded to the columns shown in the view, so even sites with hundreds of thousands of submissions render and filter in well under a second when scoped reasonably.

Where FormCraft writes payment metadata to its own table or to a meta column, SleekView reads it as another data source and adds payment columns alongside submission columns. The exact column names depend on the add-on version, but the join pattern is the same as the core submission read.

No. The FormCraft admin stays for per-submission detail and form configuration. SleekView adds the row-level workspace for the cross-form operations that work better as a sortable, filterable, inline-editable table.