Kali Forms stores each submission's field values as a serialised structure in the data column on kaliforms_submissions. SleekView parses that structure at query time and exposes the field keys as columns, labelled by the form's field configuration.

Yes. SleekView writes through Kali's submission update path for supported fields, and falls back to direct data-column writes with conflict detection on the modification timestamp. Writes respect the field's original type and any sanitisation hooks.

Yes. SleekView lets you filter on any expanded field as if it were a column. The query parses the data column for filter evaluation, applied after lighter filters like form ID and date range for performance.

Yes. Add the form ID as a column and either filter to a subset or leave it open. Only field keys shared across the selected forms become broadly useful columns; SleekView labels each field with the form it belongs to.

Yes. Payment-field values live in the same packed data column and SleekView surfaces them as sortable, filterable columns. Cross-form payment audits filter on the payment-status field directly.

Upload-field values store the file URL or attachment ID inside the packed data. SleekView renders these as filename cells linked to the file or media library, and "has attachment" works as a one-click filter.

Kali's integrations are usually configured to run on submission creation. Inline updates fire Kali's update hooks where present, but most integrations won't re-trigger on an update. Test one row before bulk-applying changes.

Parsing packed-data columns is per-row; SleekView paginates the query and applies lighter filters first (form, date, status) before parsing data for the resulting page. Indexes on form ID and date keep the base query fast.