Bit Form stores each entry's field values as JSON in bitforms_form_entries.data. SleekView parses that JSON at query time and exposes the keys as columns, labelling them with the field names from bitforms_form. New form fields appear immediately because the parse is dynamic.

Yes. SleekView updates the JSON data column through Bit Form's REST API where supported, and falls back to direct table writes with conflict detection on the entry's modification timestamp. The write respects the field's original type so booleans stay booleans and numbers stay numbers.

Yes. SleekView uses MySQL's JSON path functions to filter on values inside the data column, so "payment_status equals paid" or "score greater than 80" works as a column filter without per-form configuration.

Yes. Add form_id as a column and either filter to a subset of forms or leave it open. Only fields shared across the selected forms become broadly useful columns; SleekView labels which fields belong to which form so the chooser stays readable.

Upload-field JSON stores either the file URL or an attachment reference. SleekView renders these as filename cells linked to the file. The filter "has attachment" checks for the presence of the field key in the JSON.

When SleekView updates an entry through the REST API, Bit Form's integration hooks fire as configured. Most integrations are set to run on entry creation, so an update won't re-fire them automatically. Test one row before applying changes in bulk.

JSON parsing is per-row; SleekView paginates the table and applies non-JSON filters first (form, date, status) before parsing JSON for the resulting page. Indexes on form_id, status, and created_at keep the base query fast.

Conditional logic is form-builder behaviour that affects what users see when submitting. After submission, the stored JSON reflects only the values that were actually submitted. SleekView shows those values directly; fields hidden by conditions simply have no entry in the JSON for that row.