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 to conversational forms by form_type so the cards stay focused.

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 show up as a separate slice and the completion-vs-partial donut becomes possible.

source_url is captured natively when the submission is recorded and stored on the fluentform_submissions row. The donut groups by exact URL; for cleaner reporting on busy sites, normalise the URL in a derived column (strip query strings, lowercase) so visually identical pages collapse into one slice.

The hosted standalone form URL is just another value for source_url when the conversational form is reached through it. Charts split it like any other source page, useful for measuring how much traffic comes via the standalone URL versus embedded placements.

Live. SleekView Charts queries the Fluent Forms tables directly, so a card refresh reflects conversations up to the moment of the request. There is no separate sync that can fall behind.

Yes. Group on form_type so the dashboard shows both alongside each other for comparison, or run two separate dashboards if the audiences are different. The data sits in the same table either way.

No. Chart queries hit existing Fluent Forms indexes on form_id, status, and created_at. Aggregations are bounded by the date range or filter on each card, so even very large submission tables return chart numbers in well under a second.

Yes. SleekView views, including chart dashboards, embed on a frontend page with role-based access. Useful for sharing source and trend data with marketing stakeholders who do not have WordPress admin access.