Yes. fluentform_transactions and fluentform_subscriptions are exposed as their own views, joinable to fluentform_submissions by submission ID. Useful for refund audit (failed payments, partial refunds), subscription renewal tracking, and reconciliation against Stripe or PayPal payout reports without a separate analytics layer.

Yes. SleekView writes through Fluent Forms' submission API where supported, falling back to direct table writes for the cases the API doesn't reach. Conflict detection warns if the row changed since you opened it. Bulk operations iterate through the API per row so any registered hooks (notifications, integrations) fire as expected.

Fluent Forms stores per-field values as rows in fluentform_entry_details keyed by field_name and sub_field_name. SleekView pivots them at query time so each submission becomes one row with named columns. New fields show up immediately — no export step, no migration, no one-time setup beyond picking which keys to surface.

Yes — payment_status, payment_method, currency, payment_total, and total_paid are first-class native columns on fluentform_submissions. Filter and sort by any of them without joins. Combine with the transactions table for full payment lifecycle visibility — initial charge, refund, chargeback — in one related view.

Yes. country, city, browser, and device are columns on fluentform_submissions directly, populated from the IP at submission time. Filter "all submissions from Germany on mobile this month" with no joins. Geo accuracy depends on which Fluent Forms version captured the data — older entries may have nulls if the feature wasn't enabled at submission time.

All the storage tables exist in the free version, including fluentform_submissions and fluentform_entry_details. The geo capture and payment fields are populated only when those features are enabled and configured — they're columns on the table either way. Pro-only features like advanced reporting won't change what SleekView reads, since SleekView goes to the database directly.

Conversational forms write to the same fluentform_submissions and fluentform_entry_details tables — the entry shape is identical, only the front-end UI differs. So conversational submissions appear in the same cross-form view alongside classic forms. The source_url column tells you which page the entry came from if you want to scope a view to conversational pages only.

Fluent Forms hooks into WordPress's privacy-tools framework for exports and erasure. SleekView is read/edit only — it doesn't change retention behaviour. You can build a SleekView filtered to a specific email to confirm what data exists for a subject before issuing erasure, then run the standard WordPress privacy-tools delete for the actual purge.