Only the WordPress-side data the SmartEmailing plugin already writes: submission rows from the local log, per-form contact-list mappings from wp_postmeta and settings from wp_options. SmartEmailing contacts and double opt-in confirmation state are not duplicated into WordPress.

No. Contacts, campaigns and double opt-in confirmation stay in the SmartEmailing SaaS, which is exactly where they belong. SleekView surfaces the WordPress half of the bridge: what was submitted, by which form, to which list and with which consent state on the WP side.

Yes. The plugin writes bridge mappings to each form plugin's standard postmeta location, and SleekView reads all three. A mixed-form site produces one clean dataset with a source_plugin column for grouping.

Yes. Save a view scoped to contactlist_id and the table narrows to a single SmartEmailing contact list. The view can be shared with the marketer responsible for that list so they open straight into the right slice.

Yes. The consent flag is a boolean the plugin records per submission. SleekView renders it as a badge and a save-to-view filter, so a missing-consent slice becomes a one-click report for a quarterly legal review.

No. SleekView queries options and postmeta on read, never on write. Submissions continue to post through the SmartEmailing plugin's runtime path with no added work, which keeps visitor-facing latency unchanged.

Some SmartEmailing plugin versions disable local submission logging by default. SleekView shows an empty state on the submission rows in that case, and the mapping columns over wp_options and wp_postmeta keep rendering so the view stays useful for audit work.

Yes. Each saved view is scoped by WordPress capability. Marketers see the contact-list slice while legal sees the consent slice, with each role saving its own filter presets on the SmartEmailing dataset.