Only the WordPress-side data the Robly plugin already writes: submission rows from the plugin's log option and list-mapping rows from the plugin's settings option. Robly contacts, OpenGen sends and reporting are not duplicated into WordPress.

No. Lists, automations, OpenGen and reporting stay in Robly, which is the right tool for them. SleekView surfaces the WordPress half of the bridge: what was submitted, when, with which mapping and from which page.

Settings, the API key and per-list mappings live in wp_options. Submission audit rows are persisted in a dedicated option array on most plugin versions, with newer builds occasionally using a custom table. SleekView reads either path and pivots it into named columns.

Yes. Save a view scoped to list_id and the table narrows to a single Robly list. The view can be shared with the marketer responsible for that list so they open straight into the right slice without rebuilding the filter.

No. SleekView queries the plugin's option store on read, never on write. Signup submissions continue to post through the Robly plugin's own runtime path with no added work, which keeps visitor-facing latency unchanged.

Some Robly plugin versions disable the audit log by default. The table shows an empty state with a one-line hint to enable logging in the plugin. The mapping columns over wp_options continue to render so the view is still useful for audit work.

Yes. Any filtered set exports to CSV with the visible columns. Legal teams use the export to archive a consent snapshot and marketing reconciles it against Robly's own list reports when the cloud and the bridge disagree on numbers.

Yes. Each saved table view is scoped by WordPress capability. Marketers see the signup ledger while legal sees the consent slice, with each role saving its own filter presets on the same Robly dataset.