It replaces the admin-side use of Views (building tables and listings for staff). Front-end Views (public-facing directories rendered with shortcodes) are still a job for Formidable Views. SleekView focuses on WP Admin: cross-form tables, filtered triage workspaces, and inline editing.

SleekView joins frm_item_metas to frm_items by item_id and reads frm_fields for the field label and type. Each unique field becomes an addable column at query time, so newly added form fields appear immediately without a rebuild step.

Yes. SleekView writes through Formidable's entry update API where the field type is supported (text, email, number, select, checkbox, date). For field types the API doesn't fully expose, SleekView writes directly to frm_item_metas with conflict detection on the row's updated_at.

Repeating sections in Formidable create child entries linked by parent_item_id. SleekView exposes those as a related table view, with the parent entry as the anchor and child rows visible in an expanded row drawer. Aggregations like "row count" can be shown as a column.

File upload fields store attachment IDs in frm_item_metas. SleekView renders them as thumbnail or filename cells linked to the media library, and the filter "has attachment" works without per-form scripting.

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

SleekView reads the form's permission configuration in frm_forms.options and the role checks Formidable applies at the entry level. A view that includes entries from a restricted form is hidden from roles without access; inline edits still go through the same capability checks.

Drafts live in frm_items with is_draft = 1. SleekView treats them as a separate filterable state, so you can audit drafts per form, bulk-clean stale ones, or convert them by editing the flag through the entry API.