No. Conversational forms write to the same fluentform_submissions and fluentform_entry_details tables as classic forms. The difference is the form_type setting on the form record and the rendering layer on the front-end. SleekView scopes by form_type so the workspace stays focused on chat-style entries.

Submitted-and-completed conversations land in fluentform_submissions. Abandoned conversations are not persisted unless the form is configured for partial saves. Where partials are enabled, partial rows appear with a status column you can filter on; otherwise the table shows completions only.

source_url is captured natively when the submission is recorded and stored on the fluentform_submissions row. The column filters by exact URL; for cleaner views on busy sites, add a derived column that strips query strings and lowercases the URL so visually identical pages collapse into one value.

Yes. The hosted standalone form URL is just another value for source_url when the conversational form is reached through it. Filter for that URL specifically to see how much traffic comes via the standalone URL versus embedded placements.

Yes. SleekView routes write actions through Fluent Forms' API where it exposes endpoints. Tagging, status changes and notification resends fire the same hooks the entries tab fires.

Yes. SleekView views are gated by WordPress capability, so a growth or product lead with editor access reads the table without admin rights. Frontend embedding works for sharing with stakeholders outside WP Admin.

Yes. Queries hit existing Fluent Forms indexes on form_id, status and created_at. The form_type scope is one extra filter the index already serves cheaply, so even very large submission tables render in well under a second when scoped reasonably.

Yes. Drop the form_type filter and the table covers both. Group on form_type so the rows segment cleanly, or keep them in separate saved views when the audiences differ.